Context → Rules → Agents → Action

It looks elegant. It is easy to explain. It makes for a good pitch deck.

But once you start thinking like a backend engineer, the architecture becomes much more nuanced.

A production-grade multi-agent system is not just a few AI agents connected to Slack, Jira, GitHub, Outlook, or SharePoint. That is the easy version. The harder version is building the operating layer around those agents so that they can reliably understand context, respect permissions, coordinate work, take action, recover from failures, and remain observable end to end.

That is where the real engineering begins.

From AI demo to production system

A demo answers a question.

A production system completes work.

That difference matters.

When we talk about AI agents inside an enterprise, we are not just talking about a chatbot that can summarise a document or answer a question from a knowledge base. We are talking about systems that can interact with business tools, understand company-specific context, create tickets, update documents, review code, triage bugs, generate reports, escalate to humans, and make decisions within well-defined boundaries.

The moment an AI system starts taking action, the architecture has to mature.

You need to ask:

• Can the agent access only what the user is allowed to access?

• Can it explain why it took a particular action?

• Can it recover if a task fails midway?

• Can two agents coordinate on the same workflow?

• Can a human review or override important actions?

• Can the system be audited later?

• Can we measure quality, cost, latency, and business impact?

These are not minor implementation details. These are the difference between a toy system and something that can be trusted in a real organisation.

The high-level architecture

The way I think about a production-grade agentic system is through a few major layers:

Connectors
Identity & Access Control
Context & Knowledge Layer
Orchestration Layer
Agent Execution Layer
Policy & Guardrails
State & Memory
Control Plane / Observability
Human-in-the-Loop

Each layer solves a different problem. More importantly, each layer prevents the system from becoming a black-box automation engine with too much access and too little control.

1. Connectors

The first layer is the connector layer.

This is where the system connects to tools like:

Outlook
Teams
SharePoint
Slack
Jira
GitHub
Confluence
Box
OneDrive
Google Drive
Notion

These connectors bring in the raw material that agents need to reason and act.

Emails, tickets, pull requests, meeting notes, product specs, incident reports, customer feedback, documents, roadmaps, analytics, and internal discussions all become part of the broader enterprise context.

But connectors are not just API integrations. That is an oversimplification.

A good connector layer needs to handle sync jobs, webhooks, rate limits, pagination, retries, incremental updates, deleted documents, permission changes, metadata, and source-specific quirks.

For example, syncing Slack messages is very different from syncing SharePoint documents. GitHub pull requests are different from Jira tickets. Outlook email threads are different from Confluence pages.

The connector layer has to normalise all of this without destroying the original meaning and structure of the data.

2. Identity and access control

This is one of the most important parts of the architecture.

AI cannot operate safely in an enterprise if it uses one global service account for everything.

That model is risky because it can expose information to users who should not have access to it. If a user asks a support agent a question, the system should not retrieve confidential finance documents, HR documents, private engineering notes, or restricted customer data just because those documents exist in the index.

This is where identity and permission propagation become critical.

A serious architecture needs:

OAuth / SSO
User-scoped tokens
Service accounts where appropriate
ACL sync
Document-level permissions
RBAC / ABAC
Audit scope

The system needs to understand not only what information exists, but also who is allowed to see it and under what conditions.

This also affects RAG.

Permission-aware retrieval is not optional. If the vector database returns a chunk from a restricted document, the damage is already done. Access control has to be enforced during indexing, retrieval, and action execution.

In simple terms: The agent should not know what the user is not allowed to know.

3. Context and knowledge layer

The context layer is where enterprise knowledge becomes usable.

A lot of people reduce RAG to embeddings and vector databases. That is only one part of the story.

In a real system, the context and knowledge layer includes:

Parsing
Chunking
Deduplication
Metadata extraction
ACL indexing
Vector search
Keyword search
Hybrid search
Reranking
Knowledge graph
Context assembly

This layer has to take messy enterprise data and convert it into something agents can reliably use.

The challenge is that enterprise knowledge is usually fragmented. A single answer may require data from a Slack thread, a Jira ticket, a GitHub pull request, a product spec, and a customer email.

So the context layer needs to do more than retrieve “similar chunks.” It needs to retrieve the right information, from the right sources, with the right permissions, in the right order, and with enough metadata for the agent to reason properly.

Good retrieval is not just about semantic similarity. It is about relevance, freshness, authority, permission, source quality, and task fit.

4. Orchestration layer

This is the layer that is often missing from simple agent diagrams.

Agents do not magically coordinate with each other.

• If a Product Agent drafts a spec, how does the Engineering Agent know when to start implementation?

• If the Engineering Agent creates a pull request, how does the QA Agent know when to test it?

• If the QA Agent finds a bug, how does the workflow go back to Engineering?

• If the task takes 20 minutes, where is the state stored?

• If something fails, who retries it?

This is why the orchestration layer is so important. It usually includes:

Supervisor agent
Task router
Workflow graph
Event bus
Queue / scheduler
Retries and timeouts
Async execution
Webhooks and callbacks

In many systems, this might look like a hierarchical agent setup where a supervisor agent decomposes tasks and delegates work. In others, it might look more like an event-driven backend with queues, workers, and state machines.

The exact implementation can vary. But the principle remains the same:

Agents need orchestration, not just prompts.

Without orchestration, agents become isolated blocks that can respond individually but cannot reliably complete multi-step work.

5. Agent execution layer

The agent execution layer is where specialised agents perform work.

Examples:

Engineering Agent
Product Agent
Support Agent
QA Agent
Ops Agent
Research Agent

Each agent can have its own tools, prompts, memory, permissions, and evaluation criteria.

The Engineering Agent may work with GitHub, CI/CD logs, code search, and technical specs.

The Product Agent may work with customer feedback, roadmaps, product requirements, and analytics.

The Support Agent may work with tickets, help docs, customer history, and escalation policies.

The QA Agent may work with test cases, bug reports, staging environments, and release criteria.

But this is important: Agents should not act freely.

They need boundaries.

A production system should define which tools each agent can use, what actions require approval, what outputs need validation, and what data each agent can access.

The more powerful the agent, the stronger the governance needs to be.

6. Policy and guardrails

A common architectural mistake is placing “Rules” directly between Context and Agents, as if every data flow must synchronously pass through one central rule engine.

That can quickly become a bottleneck. A better way to think about it is as a cross-cutting policy layer. Policy and guardrails should apply across the system:

Input validation
Retrieval permissions
Prompt guardrails
Tool access control
Output validation
Approval policies
Compliance rules

This layer should not necessarily be a single box blocking every request. It should be enforced at multiple points in the lifecycle.

Before retrieval. Before tool calls. Before external actions. Before final output. Before irreversible operations.

For example, reading a document, creating a Jira ticket, commenting on a GitHub PR, sending an email, and deleting a resource are not equal-risk actions. They should not have the same approval flow.

Good policy design is risk-aware.

7. State and memory: agents need continuity

Another underrated part of agentic architecture is state.

Most useful work does not happen in a single request-response cycle.Real workflows are long-running.

An agent may need to:

Investigate a bug
Read logs
Check recent deployments
Open related Jira tickets
Review a pull request
Ask for human approval
Wait for CI to finish
Update a customer-facing response
Close the loop with support

That workflow may span minutes, hours, or even days. So the system needs state and memory.

This includes:

Workflow state
Task history
Short-term memory
Long-term memory
Conversation memory
Checkpoints
Agent scratchpads

State allows the system to pause, resume, retry, recover, and explain what happened. Without state, the system is just a stateless chatbot trying to behave like a worker That does not scale.

8. Async execution

Many agent tasks are not instant. Running tests takes time.

• Building a branch takes time.

• Waiting for a GitHub webhook takes time.

• Syncing documents takes time.

• Generating a report from multiple sources takes time.

• Getting human approval takes time.

This is why asynchronous execution is a core part of the system, not an implementation detail.

A serious backend needs:

Job queues
Workers
Schedulers
Webhooks
Callbacks
Retries
Dead-letter queues
Timeout handling

This allows the system to handle long-running workflows without blocking the main interaction.

It also makes the system more resilient. Failures can be retried. Jobs can be resumed. Dead tasks can be inspected. Humans can intervene where needed.

9. Control plane and observability

Once agents start taking action, observability becomes non-negotiable.

You need to know what the system did, why it did it, which tools it used, what context it retrieved, how much it cost, how long it took, and whether the output was useful.

The control plane should include:

Logs and traces
Metrics and KPIs
Audit trails
Evaluations
Cost monitoring
Configuration
Incident visibility
Human review flows

For traditional software, observability tells you whether the system is up.

For AI systems, observability also needs to tell you whether the system is good. That means tracking quality, accuracy, hallucination rates, retrieval quality, tool-call success, task completion rate, escalation rate, approval rate, and business impact.

The system should be measurable not only at the infrastructure level, but also at the reasoning and workflow level.

10. Human-in-the-loop

Human-in-the-loop should not be treated as a fallback after everything fails.

• It should be designed into the workflow.

• Some actions should be fully automated.

• Some should require review.

• Some should require approval only above a risk threshold.

• Some should always escalate.

For example:

• Reading public documentation may not need approval.

• Drafting a Jira ticket may not need approval.

• Sending an external customer email may need approval.

• Merging a pull request should probably need approval.

• Changing production infrastructure should definitely need approval.

The point is not to slow down automation. The point is to make automation trustworthy. Human control gives the system a safe path to operate in high-stakes environments.

The real difference

The difference between a demo and a production-grade agentic system is not the model. It is the architecture around the model. A demo can answer a question.

A production-grade system needs to:

Understand context
Respect permissions
Retrieve the right knowledge
Coordinate multiple agents
Handle long-running workflows
Take safe actions
Recover from failures
Escalate to humans
Remain observable
Improve over time

That is why I find this space so interesting.

• The future is not just “AI agents.”

• The more interesting layer is the AI work execution layer around them.

• The infrastructure that connects agents to enterprise systems.

• The orchestration that allows them to coordinate.

• The permissions that keep them safe.

• The memory that gives them continuity.

• The observability that makes them measurable.

• The human controls that make them trustworthy.

That is where agentic systems start becoming real production systems, not just impressive demos.

Working as a Senior Software Engineer at ValueLabs, my day usually involves juggling complex distributed systems, tracing logs, and debugging backend logic. When you are knee deep in Python and Django configurations, context switching is the absolute enemy. Opening a bloated web browser to paste a JSON payload or a stack trace into a random web pastebin breaks that flow. It is also a massive privacy risk for proprietary code.

I needed a solution that was fast, lived entirely in the terminal, and securely synced across my machines without requiring a heavy database.

So, I built pb, a personal Pastebin CLI.

The Problem: The Note App Bloat

The modern developer ecosystem is filled with note taking applications. However, they all suffer from the same fundamental flaws when applied to quick developer workflows. They require leaving the terminal environment, they consume massive amounts of system memory, and they lock your data into proprietary formats.

I wanted a system with strict requirements:

• Local First: It must work offline and keep a local cache of files.

• Autosave: I should never lose a draft if I accidentally close the terminal window.

• Version Control: I need a durable history of my snippets to track changes over time.

• Secure Storage: It should use infrastructure I already trust and control.

The Solution: Enter Go and GitHub

While my daily professional stack leans heavily into Python and Next.js, I wanted this CLI to be blazingly fast and compiled into a single executable binary. Go was the absolute perfect language for the job.

Instead of spinning up a dedicated AWS RDS instance or a complex database to store simple text files, I realized I already had the ultimate free, version controlled storage backend at my fingertips: GitHub.

The pb CLI leverages the official GitHub CLI tool for secure authentication. When you run the initialization command, it automatically spins up a dedicated private repository called pastebin-cli-store on your personal GitHub account. This repository acts as the secure, hidden backend for all your text snippets.

Sync and Autosave

Building a synced CLI tool is incredibly tricky. You have to handle offline edits, remote conflicts, and local state management seamlessly.

Here is how the architecture handles the flow of data.

The tool utilises an intelligent local data layout stored safely under the user configuration directory.

• State Management: It tracks file metadata and pending operations locally using a journal system.

• Recovery: As you type in the built in terminal editor, pb runs a background autosave. These recovery snapshots protect your local drafts without spamming your GitHub commit history with unnecessary remote versions.

• Durable Versions: A remote, durable version is only created upon an explicit save or sync command.

If you edit a file on your work laptop and then open it on your home machine, the explicit sync command reconciles the changes. Instead of blindly overwriting data and causing data loss, the CLI safely handles conflicts by creating conflict copies.

Installation and Upgrades

One of the biggest hurdles with internal tooling is distribution. I wanted this to be installable without requiring sudo or administrator rights.

I wrote shell installers for macOS and Linux, and a PowerShell script for Windows. These scripts pull the compiled Go binary directly from the GitHub releases and place it in a user owned bin directory.

To keep the tool updated, I baked in a self upgrading mechanism. The CLI checks GitHub for a newer release approximately once a day. You can set upgrade policies to auto, prompt, or manual, ensuring you are always running the latest version without being forcefully interrupted mid thought.

Final Thoughts

Building pb was an incredible exercise in local first architecture and CLI design. It solved a highly specific itch in my daily workflow. I no longer rely on clunky web apps to store my terminal outputs. I just type pb new notes/today.txt, drop my code, and hit save.

Sometimes, the best tools are not the massive enterprise platforms. They are the small, sharp, highly focused utilities we build for ourselves.

Till next time, happy coding :)

If you’ve spent any time working with Large Language Models (LLMs), you know they have a fatal flaw: they are confident liars. They hallucinate, they have strict training knowledge cutoffs, and they know absolutely nothing about your proprietary database, private codebases, or internal company wikis.

RAG bridges that gap. It takes your unstructured data—PDFs, Notion docs, Markdown files—and turns it into a searchable, semantic engine. It fetches exact, relevant context and feeds it directly into the LLM’s brain just in time to answer a user’s question.

The Core Process: How RAG Actually Works

Before we look at the implementation, let’s map the architecture. At its heart, RAG is a two-step dance: an indexing pipeline and a retrieval pipeline.

1. Ingestion and Indexing

You don’t just dump a 100-page PDF into an LLM. You parse it and split it into manageable “chunks” (usually a few hundred tokens each) using something like a recursive character text splitter to ensure you don’t cut paragraphs in half.

Next, you pass these chunks through an Embedding Model (like OpenAI’s text-embedding-3-small). This model converts human text into a dense vector—a massive array of floating-point numbers representing the semantic meaning of the text. We store these vectors in a Vector Database (like Pinecone, Qdrant, or a pgvector extension).

2. Retrieval and Generation

When a user asks, “What is our company’s refund policy?”, we embed that query into a vector too. The Vector DB performs a similarity search—calculating the mathematical distance between vectors using formulas like Cosine Similarity:

It returns the top 5 most mathematically relevant text chunks. We then shove those chunks into the system prompt, look at the LLM, and say: “Answer the user’s question using strictly the following context.”

The Evolution of RAG Topologies

The ecosystem has rapidly evolved beyond simple similarity search. Today, we categorise RAG into several advanced architectures:

• Standard/Naive RAG: The foundational retrieval and generation pipeline.

• Corrective RAG (CRAG): Introduces a retrieval evaluator to assess the quality of fetched documents, triggering web searches if internal confidence is low.

• Speculative RAG: Predicts user intent and drafts multiple potential response pathways simultaneously to reduce latency.

• Fusion RAG (RAG-Fusion): Generates multiple variations of the user’s query, retrieves documents for all of them, and applies Reciprocal Rank Fusion to surface the absolute best context.

• Agentic RAG: Uses LLMs as reasoning agents to determine if they need to retrieve data, where to get it from, and iteratively query multiple tools until the user’s complex problem is solved.

• Graph RAG: Combines Vector DBs with Knowledge Graphs to understand complex entity relationships, solving the “scattered context” problem.

How to Build It: Choosing Your Stack

When it comes to building a RAG pipeline in Python, you generally have three paths: going bare-metal with the raw SDKs, using an orchestration framework like LangChain or use a pre-packaged library like OpenRAG.

Route 1: Close to the Metal (OpenAI & Claude SDKs)

Writing RAG entirely from scratch using the raw SDKs gives you absolute control over your token limits, error handling, and data flow. You aren’t fighting a framework; you’re just writing Python.

Typically, you use the OpenAI SDK to generate your embeddings. Once you handle the vector math and retrieve your chunks, you format the prompt yourself.

If you are using the Anthropic Claude SDK for the generation step, the code is beautifully explicit. You handle the message loop manually:

import anthropic

client = anthropic.Anthropic(api_key="your_api_key")
# You write the logic to hit your Vector DB and return strings
retrieved_context = get_vector_search_results(user_query) 

system_prompt = f"You are a helpful assistant. Answer based ONLY on this context: {retrieved_context}"

response = client.messages.create(
    model="claude-3-5-sonnet-latest",
    max_tokens=1024,
    system=system_prompt,
    messages=[
        {"role": "user", "content": user_query}
    ]
)
print(response.content[0].text)

By using the raw Claude SDK, you can manually implement Prompt Caching. If you are constantly passing the same massive 50-page company handbook into the context window, you can flag that block of text to be cached natively via the API. Claude stores it, and your API costs drop by up to 90% for subsequent queries. Frameworks often obscure these low-level, money-saving features.

Route 2: The Orchestrator (LangChain)

If you don’t want to write the repetitive glue code for parsing PDFs, chunking text, and formatting prompts, LangChain is the heavy hitter in the space.

LangChain abstracts the entire RAG pipeline into composable blocks. You don’t have to write custom vector search logic; you just declare a retriever and pipe it together using LCEL (LangChain Expression Language).

Here is what a dense, modern LangChain pipeline looks like using OpenAI for both embeddings and generation:

from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import FAISS
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# 1. Set up the LLM and Embeddings via OpenAI
llm = ChatOpenAI(model="gpt-4o")
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# 2. Assume we loaded and chunked documents earlier
vectorstore = FAISS.from_documents(chunks, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# 3. Create the prompt template
template = """Answer the question based only on the following context:
{context}

Question: {question}"""
prompt = ChatPromptTemplate.from_template(template)

# 4. Chain it all together using LCEL
rag_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
)

# Run it
response = rag_chain.invoke("What is the refund policy?")
print(response.content)

LangChain handles the heavy lifting. It runs the user query through the embedding model, queries FAISS (your local vector store), grabs the top 5 chunks, formats the string, calls OpenAI, and returns the parsed output—all cleanly executed in that rag_chain pipe.

The Trade-off: LangChain is highly opinionated. When things go wrong, debugging a massive abstract chain of runnables can be incredibly frustrating. If you need tight, granular control over your architecture, the abstraction can feel like a straitjacket. But for rapid prototyping and standardised workflows, it is unbeatable.

Route 3: OpenRAG (Pre-Packaged Stack)

You can take over your business problem immediately and implement a production-ready RAG architecture without the headache using OpenRAG

The Trade-off

You might worry that adopting a pre-packaged stack limits your flexibility. But if you truly understand the intricacies of vector search and generative orchestration, you know that building a basic RAG app takes a weekend, while building a production-grade RAG app takes months of finessing.

OpenRAG is an opinionated, open-source stack that does the heavy lifting for you. It packages everything you need into a single platform, giving you the fast time-to-market of a managed service with the zero vendor lock-in of an open-source project.

Under the Hood

What makes a pipeline like this different? It’s the time the community spent optimising the unglamorous parts of the data pipeline. It’s like sinking 100+ hours into GTA—you stop looking at the map because you know the exact layout of every back alley.

Here is a look at the architecture OpenRAG employs:

• Docling for Intelligent Ingestion: It doesn’t just use blind, fixed-character chunking. It leverages Docling to handle messy, real-world data with intelligent semantic parsing, retaining document structure and tabular data integrity.

• OpenSearch for Retrieval: Instead of a basic vector store, it utilizes OpenSearch for production-grade performance, allowing you to combine dense vector search (for semantic meaning) with traditional search at a massive scale.

• Langflow for Orchestration: The real magic is the drag-and-drop workflow builder. You get a visual interface powered by Langflow for rapid iteration, agentic multi-tool coordination, and dynamic re-ranking to filter out noise and combat context-window dilution.

• Ready to Run: It ships with a React frontend (Next.js) and a FastAPI backend hooked up out of the box.

What’s Next for RAG?

Global adoption across multiple modalities. Right now, RAG is heavily mistreated and under utilised as just a backend for “Chatbots.” It holds vastly more capability than that.

The industry is continuously working to make these architectures faster while providing an unparalleled UX. Moving forward, the focus isn’t just on PDFs—it’s on live, dynamic integrations. We are looking at pipelines that securely ingest and ground models using structured SQL Databases, Salesforce CRMs, Slack, Microsoft Teams, and other synchronous communication platforms. The future of RAG is ubiquitous enterprise intelligence.

Phil Nash breaks down the OpenRAG stack

This presentation provides an excellent technical overview of how OpenRAG combines Docling, OpenSearch, and Langflow to create a robust, production-ready retrieval architecture.

Final Thoughts

It’s an incredible time to be building software. The tools whether you choose the granular control of the Claude and OpenAI SDKs or the rapid orchestration of LangChain are right there for the taking.

Happy Coding :)

I was one of those developers. When I got my hands on OpenAI’s API, the feeling was intoxicating. Suddenly, a single engineer had the computational reasoning power to architect, perform, and implement software solutions at the scale of a big-tech corporation.

The immediate question wasn’t if I should build something, but what to build.

Finding the Friction: The Birth of Describe AI

When brainstorming a use case, I wanted to solve a tangible problem that hindered developers on a daily basis. I gravitated toward a universal pain point in software engineering: code comprehension, documentation, and the steep learning curve of onboarding onto legacy codebases.

If we could use an LLM to explain dense logic in plain English, we could save developers countless hours of reverse-engineering undocumented functions. That was the genesis of Describe AI.

We built it as a frictionless, free plugin published directly on the VS Code Extension Marketplace. The UX was dead simple: highlight a cryptic block of code, right-click, and select “Explain with Describe AI.”

Our launch strategy was virtually non-existent. We released the MVP incredibly fast, without a monetization strategy, revenue model, or marketing campaign. It was initially designed to be an internal sandbox tool—a way for us to poke at the edges of OpenAI’s capabilities.

The market response, however, caught us off guard. Within a single week, Describe AI amassed over 500 installs purely through organic discovery. We had tapped into a desperate, unmet need in the developer community. But with sudden traction comes the stark realisation of technical debt and architectural limits.

Addressing the Elephant: The Limits of Early LLMs

We quickly realised that we were running a marathon in a pair of flip-flops. While the extension worked like magic for isolated functions, it buckled under the weight of larger, enterprise-scale projects.

The reality of building on early-2023 LLM infrastructure was fraught with friction:

• Context Window Starvation: The models at the time simply lacked the memory to ingest, parse, and accurately explain long, interconnected chunks of code or multi-file dependencies.

• API Instability: The APIs were highly unreliable and lacked the fine-grained parameters needed to tweak the output deterministically to our exact standards.

• The Fragility of Prompts: “Prompt engineering” often felt more like casting spells than writing software. Tweaking a prompt to fix one edge case almost invariably broke three others, leading to a frustrating cycle of regression.

After running the service for a couple of months, we had to take a hard, objective look at the scaling trajectory. The scale was entirely out of our hands, bottlenecked by third-party compute limits.

Sunsetting the Project: The Decision to EOL

We made the difficult but obvious decision to mark Describe AI as End Of Life (EOL).

The rationale was simple: we needed to wait for the technology to catch up to our ambition. We tabled the project with the explicit understanding that we might revive it when two conditions are met:

1. The unit economics of running large models normalize.

2. LLMs evolve to handle vast, complex codebases without generating garbage output or confidently explaining “unicorn concepts” to junior engineers who wouldn’t know any better.

Final Thoughts: The Danger of Confident Lies

Building Describe AI was an incredibly fun, chaotic, and educational experience. When it worked, it felt like peering into the future of software development. But when it failed, it did so with terrifying conviction.

The greatest lesson we learned was the danger of hallucinations. The model would routinely spin up entirely fictional explanations for code logic, presenting its answers out of thin air with a level of absolute confidence that even the most seasoned senior developers would hesitate to project. And much of it was a complete lie.

We gathered invaluable feedback from this localized experiment and learned exactly where the boundaries of modern AI lie. Describe AI is dormant for now, but the lessons it taught us about building AI-native products will be foundational for whatever we build next.

Till next time, Happy Coding.

Here is a deep dive into how we architected the solution.

The Problem Statement: Catching Bad Neighbours

• The Client: A housing society management company.

• The System: They already had a fully functional CRM to manage residents, but they were dealing with a highly manual, tedious problem.

• The Issue: Residents were violating society rules—specifically, throwing garbage out of their windows.

The Solution: Our Swiss Army Knife Approach

When you have a strong foundation in backend development and distributed systems, a problem like this immediately starts looking like a data pipeline. The core idea was to break down the video into images, analyze those images, and return a structured report.

The Tech Stack

• Web Framework: Django (Later migrated to FastAPI for better asynchronous performance and speed).

• Video Processing: OpenCV.

• Machine Learning/Vision: Google Vision API.

• Infrastructure: AWS API Gateway & AWS Lambda.

• Message Broker: RabbitMQ.

The Rationale & Architecture

To make this easy to understand, think of a video not as a continuous movie, but as a flipbook of thousands of individual pictures (frames). Processing a whole video is heavy and slow. Processing specific, compressed pictures is fast and scalable.

Here is the step-by-step logic of our pipeline:

1. Ingestion: The CRM sends the video to our AWS API Gateway.

2. Deconstruction: We use OpenCV to compress the video and extract key frames (images) at specific intervals.

3. Analysis: These frames are sent to the Vision Model.

4. Mapping: The model draws a “bounding box” around the detected object (e.g., falling garbage). We then cross-reference that box’s location with our static map of the building to identify the CCTV ID and the specific window/Flat Number.

5. Reporting: We aggregate these events and send a clean JSON report back to the CRM.

Hard Work and Edge Cases

The theory is always cleaner than the execution. Passing frames to a vision model to create bounding boxes is a neat trick, but making it reliable requires rigorous data engineering.

A massive shoutout to Sai, our Data Scientist, who helped turn this concept into reality. By packaging his computer vision logic into an API hosted on AWS API Gateway and decoupling the heavy lifting with RabbitMQ, we ensured the system could handle massive spikes in video uploads without crashing.

However, the AI is only as good as its context. Our team spent long weekends manually labeling and marking each CCTV viewpoint. We had to map out the exact pixel coordinates for every Flat Number on every camera feed to create our baseline database.

We also had to engineer our way around complex edge cases. What happens if multiple incidents occur in a single video source simultaneously? To solve this, we had to coordinate with the onsite client team to update the expected response schema. We shifted the API payload from returning simple Strings to Lists of Strings, allowing the CRM to ingest multiple timestamps and Flat IDs from a single video upload.

Future Scope: Evolving the Eye

The solution is currently in its testing phase, but the client is already seeing the potential of automated surveillance. They have requested an expansion of the system’s capabilities, including:

• Acoustic Analysis: Detecting loud noises or disturbances.

• ANPR/ALPR: Identifying parked cars and automatically raising fines using registration number recognition.

• Biometrics: Shift attendance and roster management using facial recognition for estate staff.

Growing with the Cloud

If there is one takeaway from this project, it is that data is constantly evolving, and our engineering skills must scale alongside it.

Designing a pipeline that can ingest, process, and return video data seamlessly required a deep reliance on cloud infrastructure. This project coincided with me officially clearing my AWS Certified Cloud Practitioner exam. Understanding the intricacies of how the cloud shapes distributed systems—and how to architect those systems efficiently—was the exact knowledge needed to make this API a success.

Till next time, Happy Coding :)

Their core business revolved around selling customised insurance plans. To calculate the exact premiums and craft the right price for the end customer, they had built a highly complex, proprietary in-house pricing engine.

The catch? That “engine” was a monstrous Microsoft Excel spreadsheet.

They had hit the absolute limit of what a desktop application could handle. They needed a way to migrate their intricate business logic and calculations out of Excel and into a modern, scalable web application. The goal was to ensure seamless customer onboarding, retain the accuracy of their pricing algorithms, and layer a robust Management Information System (MIS) on top to monitor business growth.

The Solution: A Resilient 3-Tier Architecture

To replace a monolithic spreadsheet, we couldn’t just build a simple CRUD app. We proposed a robust 3-tier architecture designed for scalability, easy maintenance, and future growth. Drawing on heavy backend and distributed systems experience, we finalised a highly capable stack:

• Frontend: Next.js (For a fast, SEO-friendly, and reactive user interface)

• Backend: Python with Django (To handle the complex business logic and API routing)

• Database: PostgreSQL, hosted on AWS RDS (For robust relational data integrity)

• Containerization: Docker (Ensuring environment parity across staging and production)

• Message Broker: RabbitMQ (For handling asynchronous background tasks)

• Caching Layer: Redis (To speed up repeated pricing calculations)

• Storage: AWS S3 (For static files and document management)

• CI/CD: GitHub Actions deploying to AWS (ECS/EC2)

Structuring the Chaos: The Data Model

The first step was untangling the spreadsheet’s chaotic data into a clean relational database schema. We designed a straightforward entity-relationship model.

While I can’t expose the proprietary fields or the meta-data handling the core business logic, the high-level schema consisted of distinct models for:

Users, Customers, Plans, Insurance Companies, Pricing Rules, Family Demographics, Invoices, and Payments.

The Migration Nightmare

When we scoped the migration, we fell into a classic engineering trap: How bad could a spreadsheet really be? We severely underestimated the beast.

It wasn’t a flat table of data. The spreadsheet was a horrific labyrinth of hundreds of interconnected worksheets, hidden columns, nested conditional statements, and localised macros. Standard data extraction libraries like pandas or openpyxl simply choked on the complexity. We couldn’t just read the file; we had to parse its logic. This required serious R&D.

The Custom Parsing Engine & MapReduce

To solve this, we looked outside standard data-entry scripts and borrowed a concept from big data processing: MapReduce.

MapReduce is a programming model used for processing and generating large datasets via a parallel, distributed algorithm. In a traditional sense, it involves a “Map” step (filtering and sorting data into key-value pairs) and a “Reduce” step (aggregating those results).

Here is a simplified Python example of the concept:

from collections import defaultdict
from multiprocessing import Pool

# Sample data: List of lines from a document
data = [
    "This is a sample document",
    "This document is a sample"
]

def map_function(line):
    words = line.split()
    # Emits a key-value pair for each word
    return [(word, 1) for word in words]

def reduce_function(mapped_data):
    word_count = defaultdict(int)
    for word, count in mapped_data:
        word_count[word] += count
    return word_count

# Map step: Apply the map function in parallel
with Pool() as pool:
    mapped_data = pool.map(map_function, data)
    
# Flatten the nested list of lists
mapped_data = [item for sublist in mapped_data for item in sublist]

# Reduce step: Combine the mapped results
reduced_data = reduce_function(mapped_data)

print(reduced_data) 
# Output: {'This': 2, 'is': 2, 'a': 2, 'sample': 2, 'document': 2}

We built a custom algorithm based on this exact architecture.

Instead of reading the entire Excel file linearly (which kept crashing out of memory), we built workers to map specific artifacts—extracting rules, hidden column values, and pricing modifiers from individual sheets simultaneously. The reduce function then grouped these fragmented pieces of logic into coherent Python dictionaries that matched our Django models. Finally, a database loader script took these aggregated dictionaries and mapped them to the correct PostgreSQL tables.

Bridging the Gap

The parser wasn’t 100% flawless, but it did exactly what we needed it to do. We completed the migration well within the strict client deadline with less than a 5% data loss rate.

Because the final 5% consisted of deeply corrupted or circular logic within the original sheets that our scripts couldn’t access, we resolved it via manual data entry. To ensure the client was never locked in, we also generated robust seeder scripts. If they ever decide to migrate away from AWS RDS or Postgres in the future, they have a clean, automated way to populate their new databases.

Final Thoughts

Not all solutions can be found in a neat GitHub repository or at the bottom of a Stack Overflow thread. Sometimes, you have to look at an architectural paradigm designed for massive Hadoop clusters and apply it to a terrifying spreadsheet from Miami.

Engineering is about thinking outside the box, building custom tools when the standard ones break, and constantly optimising the result.

Till next time, happy coding :)

While the company had multiple verticals, I was embedded in the B2B engineering team. Our mission was to build a robust platform that bridged a massive gap: connecting agents stationed physically inside hospitals with back-office operators managing the labyrinth of insurance claims.

Here is a deep dive into the engineering challenges we faced, the tech we deployed, and how we solved real-world healthcare financing problems.

The Problem: A Broken Healthcare Financing System

Insurance penetration in India is notoriously low. To make matters worse, a large segment of the insured population has low credit scores. When a medical emergency strikes, people are often forced to take on predatory loans just to get admitted.

Even if you have good insurance, the companies are notorious for their claim processes. Claims are frequently delayed, aggressively negotiated down, or outright rejected exactly when the patient is most vulnerable.

The Solution: The Bima Garage Ecosystem

The business model was designed to absorb this headache. For a one-time processing fee (or a yearly subscription), Bima Garage takes over the entire claim process.

To understand the engineering requirements, you have to look at the two primary user journeys on the hospital floor:

• Scenario A (The Insured Patient): You have an accident and rush to the hospital. You are in no condition to navigate paperwork. Our partnered agents, stationed right at the hospital, use our platform to onboard you. From that moment, the back-office team takes over the entire headache of battling the insurance company for your claim.

• Scenario B (The Uninsured Patient): You rush to the hospital but have no insurance (or your claim is denied). The hospital agent onboards you into our system. Bima Garage (acting as an NBFC - Non-Banking Financial Company) steps in to finance the hospital bill directly. You then pay back the amount in simple EMIs at a nominal interest rate.

The Architecture & Tech Stack

To support this, we needed an architecture built for high availability and low maintenance.

• Core Backend: Python & Django

• Frontend: React (Web) & React Native (HobNob App for Android/iOS)

• Database: PostgreSQL

• Infrastructure: Docker & Kubernetes (K8s)

The system featured multiple endpoints connecting our mobile app (HobNob) used by hospital agents, and our web portal (Desk) used by the back-office. When a customer was onboarded, the system required only minimal data points and a unique identifier (like a Mobile Number or National ID) to track the entire lifecycle of the case.

During my tenure, we built several critical features to make this engine run. Here are the highlights.

1. The Credit Scoring & Financing Engine

When an uninsured patient (Scenario B) needed immediate financing, time was critical.

Once onboarded, our platform automatically reached out to secure third-party vendors to fetch the patient’s CIBIL (credit) score. Using this data alongside the estimated medical costs, our internal scoring algorithm evaluated the risk. It then generated a recommendation for our banking partners on whether to approve the loan and at what interest rate.

Because patients and their families are highly anxious during this time, communication had to be instant. We built an event-driven notification system.

Every time a database row updated its status, a Django Signal fired. This handed the task off to a Celery background worker, which communicated with AWS SNS to blast out WhatsApp and Email updates.

2. Automating Repayment with eNACH

Financing a medical bill is only half the battle; collecting the EMIs reliably is the other half.

We initially evaluated standard payment gateways like Paytm and Razorpay. However, for recurring B2B invoicing and B2C loan repayments, we needed something that required absolutely zero human intervention month-over-month. We chose to integrate eNACH (Electronic National Automated Clearing House).

By having the user register a one-time eNACH mandate, our system was authorised to automatically pull the EMI amount directly from their bank account on a specific date. It also allowed us to pause or cancel the mandate dynamically via code if their repayment plan changed.

High-Level Design (HLD) for eNACH Flow:

3. Hacking Turnaround Time (TAT) with Email Automation

For a long time, our biggest operational bottleneck was manual claim tracking. Back-office employees had to constantly refresh portals and check inboxes for status updates from the Insurance Companies. This resulted in massive Turnaround Times (TAT).

Guided by a senior Solution Architect, we built a clever workaround: The Email Polling Engine.

We set up scheduled cron jobs in our task queues that constantly polled our dedicated claims inboxes. Using Python’s scraping libraries and email parsing techniques, we created scripts that could “read” the automated emails sent by various insurance companies. The script would extract the claim ID, identify the status (e.g., “Query Raised”, “Approved”, “Rejected”), and automatically update our PostgreSQL database.

What used to take hours of manual data entry was reduced to seconds, triggering an immediate chain reaction of notifications to the hospital desk.

4. Condensing Chaos: OCR and KYP (Know Your Policy)

I was handed this feature on incredibly short notice. The concept was brilliant: Insurance policy documents are generally 20 to 40 pages of dense, unreadable legal jargon. We wanted to build a feature that condensed this into a simple, 1-page KYP (Know Your Policy) summary.

To extract text from massive PDFs, we tested everything: Python’s native Tesseract, AWS Textract, and Google Cloud Vision. Ultimately, Azure Form Recognizer ticked all the boxes for speed and accuracy on unstructured Indian financial documents.

However, processing a 40-page PDF is computationally heavy. If five users uploaded policies simultaneously, it could lock up our main Django threads and crash the API.

The RabbitMQ Solution: To protect our infrastructure, we decoupled the processing. When a user uploaded a policy, the file went straight to an AWS S3 bucket, and a message was dropped into a RabbitMQ queue. The user immediately got a “Processing...” screen.

In the background, dedicated worker nodes consumed the RabbitMQ messages one by one, sent the PDFs to Azure, parsed the returned JSON, generated the 1-page summary, and alerted the user when it was done. We consistently delivered the KYP document in under 5 minutes without ever overwhelming our core servers.

Final Thoughts

Engineering at a startup teaches you that code isn’t just about syntax; it’s about solving actual, painful problems. There will always be brilliant ideas floating around, but the idea itself is cheap. It is the execution how you design the database, how you handle the queues, and how you manage the edge cases that actually matters.

Till next time, happy coding.

I’ll be honest, I was nervous. I was never the fastest at tricky aptitude tests or competitive programming puzzles. While many of my peers spent their days grinding on LeetCode and Codeforces, I had spent my time building and reading. I loved getting my hands dirty with real-world projects and digesting foundational software engineering books. I knew how to build, but I wasn’t sure if that would translate in a traditional 45-minute whiteboard gauntlet.

The Day Finally Arrives

After jumping through multiple screening hoops, I landed an interview with a company that needed no introduction Sears.

They were the absolute OG of the American retail market. While the dot-com boom and the rise of modern e-commerce had brought them some rough patches, none of that mattered to me. This was a massive enterprise with decades of history. I just wanted to contribute, write code that impacted a real business, and learn from the veteran developers on their team.

The interview was scheduled for 9:00 AM. For 45 minutes, I didn’t get asked abstract brain teasers. Instead, the interviewer dug into real engineering. I wrote complex SQL queries (nested queries, various JOINs), architected a High-Level Design (HLD) on the whiteboard, and explained the architecture of the projects I had built. My practical experience paid off. There were a few small array and string manipulation questions, but they were grounded in reality.

I spent the rest of the day pacing. Finally, at 7:00 PM, the call came and I was selected.

I was interviewed on October 7th, and my call letter told me to report to the office on October 21st, 2019. I was on cloud nine.

The Data Engineering Team

When I walked into the Sears India office, I realised I was the junior guy in a room full of titans. The data engineering team was packed with industry veterans—brilliant minds with 20+ years of experience from product development giants like Adobe, IBM, and HCL. I was thrilled.

The first two weeks were a whirlwind of Knowledge Transfer (KT) sessions, reading endless documentation, and getting access to Google Cloud Platform (GCP). Every week, we had assessments to ensure we were absorbing the architecture.

Once the training wheels came off, I was introduced to the monster problem the team was tackling.

Moving a Mountain of Data

Sears owned a staggering amount of legacy infrastructure. We are talking about petabytes of consumer and transactional data sitting on aging IBM Power Systems, Hadoop clusters, and Teradata.

The business goal was modernisation: this massive ocean of data needed to be migrated to Google Cloud specifically into BigQuery and Spanner—so the business could run modern data analytics.

Every week, the onsite team in the US would provide us with the DDL (Data Definition Language) and DML (Data Manipulation Language) for the incoming downstream data. Our job in India was to write the pipelines to catch that data, transform it, and load it into the new cloud tables.

Our Tech Stack: Python, Shell Scripting, PySpark, Apache Airflow, Control-M, and massive amounts of BigQuery/Spanner SQL scripting.

What exactly is ETL?

If you are new to data engineering, you might hear the term ETL thrown around a lot. It stands for Extract, Transform, and Load. It is the backbone of almost every big tech company that relies on data.

Imagine you are running a retail giant that has been in business for decades. You process millions of transactions a day across thousands of stores. To survive, you need an analytics engine that tells you: What is our warehouse stock looking like? Which city is growing the fastest? Which winter jacket is failing in the market?

To answer these questions, you need all your data in one place, perfectly formatted.

• Extract: We pull the raw data out of the old legacy systems (like the IBM Power Systems).

• Transform: The raw data is often messy. We clean it, fix data type mismatches, remove redundancies, and shape it to match the new system’s rules.

• Load: We push this clean, organised data into a modern database where it can be analyzed.

Here is a visual breakdown of how this pipeline works

The Database Dilemma: OLTP vs. OLAP

The reason Sears needed to migrate the data was fundamental to how databases work. The legacy IBM Power Systems were incredibly secure and fantastic at writing data as transactions happened. But they were terrible at reading massive chunks of data for analytics.

This introduces the two main categories of database processing:

1. OLTP (Online Transaction Processing)

Think of OLTP as the cashier at a supermarket. It needs to be incredibly fast at handling thousands of small, short requests at the same time (inserting a new sale, updating inventory, deleting a canceled order).

• Focus: Fast, real-time transaction processing.

• Structure: Highly normalised (organised to avoid duplicate data).

• Users: Thousands of point-of-sale systems or end-users.

• Examples: Banking apps, Amazon checkout, airline ticket bookings.

2. OLAP (Online Analytical Processing)

Think of OLAP as the CEO sitting in a boardroom analyzing a 10-year trend report. It doesn’t handle real-time sales; it looks at historical data from different perspectives.

• Focus: Analysing massive volumes of data with complex queries.

• Structure: Denormalised (data is grouped together to make reading much faster, even if it takes up more space).

• Users: A small number of data scientists or business analysts.

• Examples: Tableau, Data Warehouses, customer trend analysis.

Choosing the Right Cloud Tool: BigQuery vs. Spanner

When loading data into Google Cloud, we didn’t just throw it all into one bucket. We had to route it based on what the business needed to do with it. This is where the difference between BigQuery and Spanner becomes crucial.

Final Thoughts

The world of software and data engineering is endlessly fascinating. If there is one thing I learned during those early days at Sears, it is that there is no “one size fits all” silver bullet in technology.

You can never understand or solve all problems with a single tool. Every database, language, and framework has its own specific magic. Our job as engineers isn’t to blindly use the newest tech; our job is to understand the problem deeply enough to figure out exactly which tool to use, and exactly when to use it.

And if the right tool doesn’t exist? Well, then we get to build a new one.

I was completely captivated by the startup ecosystem. Reading about the meteoric rise of companies like Flipkart, Snapdeal, and Amazon left me highly motivated. I loved the romantic idea of a founder and a tight group of friends building something from nothing and turning it into a real, breathing business.

The Catalyst: Our Fifth Semester Project

Then came the fifth semester of my Computer Science and Information Technology degree at SOA University. Right in the middle of the semester, we were assigned a major assessment. The requirement was simple but daunting: build a real world application.

This was exactly the excuse I had been waiting for.

We quickly formed a team of four. It included me, my best friend from college, and two other close friends. We chose our team based on complementary skills. The things I was rough around the edges on, they excelled at.

• Anurag was the talker and an absolute natural at sales.

• Prasanna was a solid coder who could bring technical ideas to the table.

• Jyoti was the ultimate hard worker, making him the perfect person to meticulously document our journey and compile our massive 150 page project report.

• My role was to coordinate everyone, brainstorm the core ideas, and keep the project moving forward.

The Tech Epiphany: Discovering Web Builders

Back in 2018, Android development was the absolute hottest trend. Everyone on campus wanted to build a native mobile app. However, during our research and development phase, my path took a different turn. I discovered a tool that allowed you to build fully functional websites using a visual interface.

That tool was WordPress.

I was ecstatic to learn that I could build a working website in a single day and host it for under 100 rupees. I built a few test sites and showed them to the class the next day. They were an instant hit. The entire team agreed we should pivot and build our major assessment around this web technology.

Product #1: Identifying the Problem

We brainstormed for a few days and finally landed on a solid concept.

The Problem Statement: SOA University attracts students from all over the world. However, there was no centralized, official forum where these students could connect. They had no place to share their thoughts or figure out which nearby local spots were safe, cool, and worth visiting.

The Solution: To solve this, we created ITER Community (named after our specific college, the Institute of Technical Education and Research).

We got to work immediately. Anurag hit the streets to catalog local businesses. He gathered pictures, contact information, and negotiated exclusive offers for students. We did not offer these businesses any money. Instead, we promised to drive foot traffic and increase their sales if students liked their ambiance.

But how would we populate the platform with initial reviews? Fortunately, we knew enough basic coding to read API documentation. We wrote web scraping scripts in Python to gather publicly available Google reviews and populate our initial database.

Hosting and Architecture on a Budget

Since we were broke college students, our hosting strategy was entirely bootstrapped. We relied on free DNS providers (which resulted in a very weird domain name), standard cPanel hosting, and initial testing on a local XAMPP server.

We needed three main features: a search function, a database to fetch business information, and an easy way for users to log in. We explicitly wanted to avoid touching any official University ID data to dodge privacy and security issues. So, we integrated OAuth2 via Google Sign In.

For the forum and review section, which was the trickiest part to build from scratch, we plugged in Disqus to handle comment threads. We wrapped the entire thing in a free, kick ass theme, and we were live.

Going Kind Of Viral on Campus

The platform exploded. We started receiving so much traffic that our server routinely hit 95% CPU utilization.

We did not know anything about advanced analytics or Daily Active Users at that time. However, our database told the real story. We gained over 13,000 unique users via Google Sign In and accumulated a staggering 40,000 comments across the platform. We knew we had a massive hit on our hands.

We presented the project for our major assessment and received top grades and stellar feedback. But with great traction comes great scrutiny. University officials eventually noticed the platform. Because we were using the ITER name, they wanted to take control of the code and add a layer of official governance.

My friends and I realized this could become a liability. On top of that, the heavy placement season was rapidly approaching.

And Then We Hit Sales

We spent two months trying to figure out a moderation system, but ultimately decided it was time to shut the servers down and focus on our careers. But before we could pull the plug, we got an unexpected message.

A local entrepreneur was opening a new restaurant in the area and had heard about our platform’s reach. He understood technology and saw the value in our system. He approached us with an offer to buy the codebase so he could customize it into an app for his own customers to read reviews and book tables.

We discussed the offer as a team, negotiated a final price, and closed the deal. We spent our final week on the project helping the new owner take control of the servers. It was a perfect, real world lesson in supply and demand.

Final Thoughts

That project taught me that you do not need millions of dollars in funding to build something valuable. You just need a good team, a clear problem, and the willingness to figure things out as you go.

Hit the subscribe button to motivate me and help me understand the demand for this kind of content. I promise to keep sharing my journey through software development without ever spamming your inbox!

CRMs are everywhere. If you are looking for popular examples in the market today, you will find:

• Frappe (An open source option built using Django)

• Odoo

• Salesforce CRM

• Microsoft Dynamics

• HubSpot CRM

• Freshworks CRM

They are the digital backbone of modern commerce. Businesses are run by humans (at least until AI takes over completely), and every growing business handles massive volumes of customer data. A CRM is the management software that sits in the middle. It helps the business manage bookkeeping, invoicing, and all sorts of daily transactions. Think of it as a highly advanced Library Management System, but instead of tracking library books, you are tracking people, assets, and money.

My First Internship

This brings me back to where my software journey really started. The year was 2017. I had just landed my very first internship as an IT Developer at the Tinplate Company of India in Jamshedpur.

I was handed a massive responsibility for an intern. The organisation tasked me with building an internal CRM solution. They needed a centralised platform to manage their employees and track their hardware assets.

The Problem Statement: The company wanted an internal web portal. Employees needed to log into the system, view their assigned IT assets (like computers and electrical devices), and create service tickets if they encountered any hardware issues.

The constraints were strict. The tech stack had to match the organisation’s existing infrastructure. We had to use C#, .NET, Bootstrap, and MySQL. Furthermore, the entire development and testing lifecycle had to be completed within 45 days using Agile methodologies.

The Execution and The Reality Check

We had a team of five interns. We quickly divided the workload and assigned ownership based on our strengths:

• Dev A: Data Modeling and Architecture

• Dev B: UI and UX

• Dev C: Database Integration

• Dev D: Testing

• Dev E: Core Logic and Coding

After a couple of days of deep research and heavily relying on Stack Overflow, we mapped out our Entity Relationship models and Data Flow Diagrams on a whiteboard. Once we understood how the data would move through the system, we built our first prototype and went in for our first review.

The review was a brutal but necessary learning experience. We received a lot of feedback on the UI. The core issue was that we had completely over engineered the design.

The biggest takeaway from that meeting was a fundamental rule of UX. Factory employees are not always tech savvy. They will not spend more than five minutes trying to understand how to log in or navigate a complex menu just to report a broken mouse.

We went back to the whiteboard with a completely different perspective. We redesigned the interface to put “Actions” front and center. When a user logs in, the first thing they see should be the exact buttons they need to create a ticket or view an asset. By making their intentions clear immediately, users spend time actually doing things rather than trying to figure out how the application works.

Keeping it Simple

For the backend, we opted for a monolithic approach to keep infrastructure costs and complexity low.

We hosted the static files directly on the local Windows server. The IT department provided us with credentials to an internal MySQL instance.

Coming from a Python background, learning C# on the job was fascinating. The architecture followed the MVC (Model View Controller) pattern. We utilised parent templates and child templates to keep the frontend code clean. Writing the backend logic helped us practically understand core Object Oriented concepts like abstraction, encapsulation, and inheritance.

We completed the V1 build well within the 45 days. The senior developers were happy, and the application was pushed to their staging environments the very next week.

Phase 2: The Scope Creep

Our initial development was successful enough that the management team extended our internship by three more weeks. Naturally, with extra time came extra requirements.

We were tasked with adding three major features:

1. Barcode and QR Code Support

2. Email Notifications

3. Proper Ticketing Chain Management

When we released V1, the ticketing module was essentially a baby. It was purely unidirectional. If an employee created a service ticket, the system sent a simple SMS to the IT team and attached a basic status flag in the database. When the issue was fixed, the ticket was marked closed.

But what happens if the ticket is reopened? The old system had no history log.

Furthermore, manually typing in IT asset serial numbers was time consuming and prone to human error. We needed to implement Barcode and QR code scanning. We also had to upgrade our notification channels from basic SMS text messages to detailed emails.

We received massive data dumps containing over 300 rows of existing hardware assets that needed to be migrated into our new system. Our data models went through significant transformations to accommodate these new fields without breaking the existing V1 data.

We were incredibly lucky to have senior developers step in and write code alongside us during this phase. This was a heavy lift for five interns.

Final Thoughts

We completed the extended project in 31 days. We overshot our three week extension by about 10 days due to some unforeseen bugs with the barcode scanning logic, but the final delivery was a massive success.

That summer in 2017 taught me exactly what a CRM is and how modern software fundamentally reduces execution time for large organisations.