DEV Community: Malawige Inusha Thathsara Gunasekara

Reverse-Engineering an Old Node.js Crossword App into a Modern Next.js Stack

Malawige Inusha Thathsara Gunasekara — Mon, 22 Jun 2026 15:30:39 +0000

As an IT undergrad at the University of Moratuwa, I’ve built my fair share of projects. Recently, I looked back at an old project of mine—a traditional Node.js Crossword App and realized it was time for a complete teardown.

The old app worked, but the architecture felt dated. I wanted to modernize it, improve the performance, and implement a cleaner, editorial-style UI. Instead of just refactoring, I decided to reverse-engineer the core logic of my own app and rebuild it from the ground up using Next.js 16, Neon PostgreSQL, Better Auth, and v0 by Vercel.

Here is how I broke down the legacy system and engineered the new application, Crosshatch. You can check out the live deployment here: crossword-web-app.vercel.app

The Teardown: Reverse-Engineering the Core Loop

When reverse-engineering an existing app—even your own—the goal is to separate the underlying business logic from the legacy plumbing. I ignored the old routing and view layers and focused entirely on the data structures and the game loop.

I identified three critical systems that needed to be extracted and modernized:

Grid Generation: How words intersect and fit into a 10x10 matrix.
State Management: Tracking user input, active cells, and directional navigation (Across vs. Down).
Session & Progress: How to persist a user's progress without hammering the database.

Once I had the core logic mapped out, I started the rebuild.

Accelerating the UI with v0

I wanted the new app to have a calm, newspaper-inspired light theme. To move fast, I leveraged v0 by Vercel to generate the initial React components.

By prompting v0 with my required game state constraints (e.g., handling keyboard events like Tab, Shift+Tab, and arrow keys for navigation), I was able to rapidly prototype the 10x10 interactive grid. v0 handled the Tailwind CSS boilerplate, allowing me to focus on wiring up the complex state machine using a custom useCrossword React hook.

The Modern Stack & Architecture

With the UI taking shape, I built out a robust backend architecture to support it.

Framework: Next.js 16 (App Router)
Database: Neon PostgreSQL with Drizzle ORM
Authentication: Better Auth (handling secure email/password flows and session management)

Here are the key technical problems I had to solve during the rebuild:

1. Deterministic Puzzle Generation

In the old app, puzzle generation could be unpredictable. For the new build, I implemented a Seeded RNG algorithm. By using the puzzle's ID (e.g., animals-1) as the seed, the generation is completely deterministic. It shuffles the word list, places the first word at (0,0), and maps intersecting cells. If you and a friend both load animals-1, you are guaranteed to get the exact same layout.

Because generating a puzzle is CPU-intensive, I implemented a caching layer. The server generates the puzzle once, caches it in a Map, and serves it instantly on subsequent requests.

2. Smart Autosave & The Visibility API

Losing crossword progress is frustrating. I built a system that autosaves every 5 seconds. To prevent excessive database writes, I used a PostgreSQL UPSERT pattern via Drizzle:

INSERT INTO puzzle_progress (userId, puzzleId, entries, elapsedSeconds)
VALUES ($1, $2, $3, $4)
ON CONFLICT (userId, puzzleId)
DO UPDATE SET entries = $3, elapsedSeconds = $4, updatedAt = now()

Additionally, the puzzle timer uses the browser's Visibility API. If you switch tabs, the timer automatically pauses, ensuring your "Solve Time" stats remain accurate to your actual active playtime.

3. Data Integrity: The "No Double-Credit" Problem

I built a user dashboard to track completions, best times, and average solve times. But what happens if a user submits the same completed puzzle twice?

Instead of writing complex application-level checks, I let the database handle it. I added a unique constraint on (userId, puzzleId) in the completion table and utilized the ON CONFLICT DO NOTHING clause. If a user solves a puzzle for the first time, it records their time. If they re-submit it, the database ignores the insert, returning a response that acknowledges the correct answers without skewing their dashboard analytics.

Final Thoughts

Reverse-engineering an older project and rebuilding it with modern tooling is one of the best ways to measure your growth as a developer. By moving to Next.js and leveraging v0 for rapid UI prototyping, I was able to spend my time solving actual engineering problems (like deterministic generation and state synchronization) rather than wrestling with basic CSS.

Check out the live app at crossword-web-app.vercel.app and let me know what you think of the architecture! I’m always open to technical feedback.

Stop Funding History: Building a Demand Prediction App to Optimize Trade Spend

Malawige Inusha Thathsara Gunasekara — Mon, 22 Jun 2026 15:00:24 +0000

Let’s be honest: in the FMCG (Fast-Moving Consumer Goods) space, trade marketing budgets are almost always misallocated. Companies tend to fund invoice history rather than actual potential.

For the DataStorm 7.0 competition, our team, Stack Kings, decided to stop guessing and start modeling latent demand. We built an analytics pipeline and a Next.js field app to optimize a LKR 5M trade spend across 20,000 retail outlets in Sri Lanka. Here is the unvarnished breakdown of how we achieved a +253% lift over a naive budget allocation.

The "Empty Shelf" Problem (Right-Censoring)

The core data science issue here is a concept called right-censoring. The monthly sales volumes we observed in the 2.3M transaction records were just a lower bound. If a small shop shows low sales, it might just be under-stocked or credit-constrained, not lacking in customer demand.

Because of this, standard averages systematically underestimate a shop's true potential. Instead of using standard textbook models like Tobit—which require strict indicators of exactly when a shop ran out of stock (which we didn't have)—we built an ensemble model.

We took a two-pronged approach:

Lookalike Clustering: We clustered similar outlets to see what the top performers in that specific group were achieving, assuming that less-constrained shops reveal the true ceiling.
Upper-Tail Regression: We used a specific type of regression (Quantile Regression) designed to estimate the maximum possible demand based on a shop's features, rather than the average.

Taking the maximum of these two estimates ensured we weren't artificially pulling down a shop's potential.

Mapping the Real World (Spatial Features)

To give the models a real signal, we engineered spatial features using OpenStreetMap Points of Interest (POIs).

Rather than using arbitrary "flat disk" counts—like just counting how many shops are within a 3km radius—we implemented a distance-decay model. In plain English: a bus stop 200 meters away matters a lot more to foot traffic than one 2 kilometers away.

We grouped locations into tiers. Transport and food places have a "fast" drop-off in influence, meaning you need to be right next to them to get the benefit. Meanwhile, schools and temples cast a wider, "slower" net of influence over the entire neighborhood.

Squeezing Every Drop of Budget (The Optimizer)

Ranking outlets by potential isn't enough; you need to maximize the incremental liters gained per rupee spent.

We modeled the volume response to trade spend as a curve with diminishing returns. Simply put, the more you spend on a single shop, the less extra volume you get for your next rupee.

To solve this efficiently across 9,000 Western Province outlets, we broke that curve into straight-line segments. This allowed us to use a Linear Programming solver to allocate the LKR 5M budget mathematically perfectly. The result? A massive 253% lift compared to the standard gut-feel approach of just splitting the money evenly among top shops.

Building Trust with the Field App

stackkings.inusha.me

A complex optimizer is useless if field sales reps don't trust the numbers. They need to know why a shop is getting a certain budget.

We built a live Outlet Intelligence Web App using Next.js and Postgres. To explain the outputs, we added an Explainable AI (XAI) layer. It uses a local Ollama process (gemma3:1b) running in the browser to generate a structured SWOT summary. If the local AI is offline, it falls back to a Gemini cloud API or a safe deterministic template.

Crucially, the AI doesn't make the predictions. It simply translates our hard, pre-computed data into plain business language so the sales reps can actually use it on the ground.

The Dirty Reality of Data

Data engineering isn't glamorous. We built a strict Medallion architecture. We didn't silently drop messy data. We explicitly quarantined 37,205 records using failure reason codes. We even retained 7,417 "blackout" outlets (shops with zero December transactions), treating them correctly as supply signals rather than zero demand.

Check out the live production app at stackkings.inusha.me

We don't fund history. We fund potential.

I Made Tyre Size Detection App Using Gemma4:e4b

Malawige Inusha Thathsara Gunasekara — Tue, 19 May 2026 18:21:37 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

NewTyre-AI is a secure, localized full-stack web application designed to automate a deceptively complex industrial task: passenger vehicle tyre sidewall size extraction.

The Problem

Traditional computer vision pipelines frequently default to cloud-dependent architectures to process visual data. While convenient, this approach introduces persistent operational liabilities for businesses: recurring cloud API bills, data transit latencies, and corporate data privacy exposure. Furthermore, reading alphanumeric characters from a tyre sidewall is difficult for traditional linear Optical Character Recognition (OCR) tools because text printed on rubber is non-linear, low-contrast, heavily textured, and curved.

The Solution

NewTyre-AI solves this by shifting the entire visual processing workload onto a local, physical on-premise company server. The system ingests sidewall photos, filters them through a localized multimodal edge model, and returns an un-hallucinated, deterministic 9-character tyre size code (e.g., 205/60R16) to the technician with zero ongoing cloud compute or external API costs.

Demo

Video Demo(30 sec): Google Drive

Code

GitHub Repo

How I Used Gemma 4

For this project, I deliberately selected the Gemma4:e4b (Effective 4B) parameter model rather than scaling up to the massive dense weights or downgrading to the highly lightweight e2b version. 2B model lack the visual cross-attention layer density required to accurately map characters in noisy geometric layouts, while 32B model is a overkill. The e4b model retains the precise structural transformer resolution required to read curved, dirty text on dark rubber cylinders without throwing a wave of false positives.

Built an AI Study Tool That Refuses to Give You the Answers for UoM

Malawige Inusha Thathsara Gunasekara — Sun, 01 Mar 2026 17:10:22 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I am an IT undergraduate at the University of Moratuwa(UoM), Sri Lanka. In our community, the night before a brutal technical exam is chaotic. When faced with a massive, complicated past-paper question that we don't understand, students often hit a wall of panic and just give up (we call it going "Bora").

The problem with existing AI study tools is that they just give you the final answer or the raw code. That doesn't help you learn; it just helps you cheat. I wanted to build a tool for my batchmates that acts like a senior student holding a late-night study session(a "Kuppi") guiding you to the answer without actually giving it to you.

What I Built

I built Triage AI, a cross-platform (Next.js Web + Flutter Android) tool designed specifically for technical exam preparation. You simply snap a photo of a difficult past paper question, and the app uses AI to break it down.

Instead of solving the problem, it returns three specific things:

Core Concepts: The exact fundamental topics you need to Google to understand the question.

The Trap: It identifies the subtle pitfall or trick hidden in the question designed to make students fail.

Attack Plan: A step-by-step strategic breakdown of how to approach the solution.

If you are still stuck, Triage AI features a "Practice" mode that generates a similar question, and a "Hint" system that provides progressive, helpful nudges (never the answer) to get you unblocked.

Demo

Live: Vercel
This weekend sprint proved to me that AI doesn't have to be a shortcut that ruins learning. When built with the right constraints, it can be the ultimate teaching assistant.

Code

Source Code: Github

How I Built It

Balancing this weekend challenge with my strict university workload was tough. As an IT undergraduate, I couldn't afford to ignore my own university assignments to build an app. Because I was juggling coursework and only had the weekend to code, I needed to keep the technical setup extremely lean and fast.

The Brain: I used the Google Gemini 2.5 Flash API because it can process uploaded images incredibly fast.

The Logic: I built a Next.js application to handle the requests. I wrote strict prompts and set up Gemini to return structured data, which made it easy to display the results in clean UI cards.

The App: The Next.js backend powers both a smooth React web app and a native Flutter Android app(kinda buggy though) at the same time.

Aside from time management, the hardest technical challenge was the Hint System. To ensure the AI didn't repeat itself or accidentally reveal the answer, the app keeps track of the clues you've already seen. It sends this history back to Gemini so that the next hint is a progressively more specific nudge in the right direction.

Good luck with exams, batchmates!

How I Built a 15,000+ Line Flutter App with Gemini to "Hack" My University Attendance

Malawige Inusha Thathsara Gunasekara — Wed, 25 Feb 2026 18:55:37 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

As an IT undergraduate balancing startup ambitions and a heavy coursework load, missing too many classes can lead to disastrous exam bans. To solve this, I built Attendance Tracker (code-named "The 80%"). It's a cross-platform Flutter application designed to mathematically optimize university attendance using offline-first storage and AI.

The app features a "Danger Zone Planner" that calculates the exact margin for absences across specific sessions (Lectures, Labs, Tutorials). This allows students to simulate granular scenarios and understand their attendance buffer, ensuring they never accidentally drop below their mandatory academic thresholds.

Google Gemini played a massive, two-fold role in this project:

The Architecture (Agentic AI): This project scaled to over 15,000 lines of code. I used the Gemini 3 Pro (High) model inside the Antigravity IDE as an autonomous coding agent to help architect the offline-first database (Hive), manage state (Provider), and handle complex UI animations.
The Core Feature (API Integration): The biggest friction point in attendance apps is manual data entry. I integrated the Gemini 2.5 Flash API to handle multimodal timetable extraction. Users simply upload their official university schedule as a PDF or image, and Gemini intelligently parses the unstructured data into a clean matrix of subjects, times, and session types.

Demo

You can experience the live web app directly in your browser:

Live Web App: Attendance Tracker Web

Source Code: GitHub Repository (Only the Demo source code is available with the latest apk releases)

Screenshot:

What I Learned

Building a 15,000+ line production app taught me several critical lessons:

Background Asynchronous Processing: Because parsing detail-heavy timetable PDFs via the Gemini API can take time, I had to learn how to run these complex tasks in the background. This ensures the UI doesn't freeze, allowing users to navigate the app while waiting for an in-app "Timetable Ready" notification.
Defensive Engineering: AI isn't perfect. I learned to build a robust "Draft Review" step so users can verify and edit the AI's extracted timetable before committing it to the Firebase database.
System Design: Implementing an offline-first architecture with Hive local caching and syncing it seamlessly with Firebase Firestore taught me how to handle complex data states across varying network conditions.

Google Gemini Feedback

The Good:
The multimodal capabilities of gemini-2.5-flash are incredible. It flawlessly handled messy, poorly formatted university PDFs and images, turning unstructured visual data into a clean, usable dataset. Using Gemini 3 Pro (High) as an agentic coding partner felt like having a senior engineer on call, saving me weeks of boilerplate coding and UI tweaking.

The Bad and The Ugly:
When you let an AI agent loose on a 15,000-line codebase, you push context windows to their absolute limits. Occasionally, the IDE agent would lose the thread of the architecture, hallucinating variable names or forgetting how distant files interconnected.

On the API side, relying heavily on Gemini 2.5 Flash for file parsing introduced the reality of rate limits. To prevent the app from breaking for users during high-traffic periods, I had to engineer a Multi-API Key Support system, allowing the app to rotate through different user-provided Gemini keys to ensure uninterrupted parsing. Additionally, highly non-standard timetable layouts occasionally confused the model, making the manual draft review step an absolute necessity. Overall, it's a powerhouse, but it requires strict guardrails in a production environment.

The Shores of Denial – The World that Shouldn't Exist

Malawige Inusha Thathsara Gunasekara — Fri, 23 Jan 2026 13:23:07 +0000

My Voluntary Descent

When I first stepped onto the Fort Oasis pier as Tyler, the atmosphere was immediately suffocating. My first instinct wasn't to explore, it was to leave. I was given the functioning boat , then took the exit, and triggered the ending within minutes. But as the credits rolled, I realized I hadn’t actually played the game; I had simply committed a "coward’s move." I chose the "Safe Lie" because the reality of the island was too unsettling. I believe everyone have tried that in their first playthrough.

On my second run, I refused the boat. I stayed because I wanted the content. By staying, I felt like I was actively validating Tyler’s internal chaos. The game stopped being a survival horror and started feeling like a psychological autopsy I was performing on myself.

Navigating a Broken Mind

As I explored Fort Oasis, I realized it isn't just a game with a map; there are some metaphors. Since the game doesn't tell us the direct story, I explored the internet and found that the story explains about the terminal disease and the depression on the character I'm playing. I began to see the environment as a manifestation of Tyler’s isolation:

The Mining Colony: This is the skeletal remains of a life once filled with productivity and purpose, now hollowed out.
The Rot: The black, organic corruption "overwrite" the walls was visceral. It’s the visual language of a terminal illness that doesn't just inhabit the world but replaces it.
The Permafrost: The cold represents an emotional numbness I think Tyler uses to shield himself from the memory of Leda’s love (Leda is Tyler's wife). It is the "Distant Embrace" of a death that has already begun.

The Realization of the Mission

In the beginning, I followed the story believing I was on a rescue mission. However, the deeper I went, the more I felt manipulated. I wasn't there to save a colony; I was there to witness the final shutdown of me(actually the Tyler).

The most haunting part of my experience was the silence. Before the monsters ever appeared, the weight of being all alone in a dying world was more terrifying than any jump-scare. That silence is the bridge between Tyler’s past and the "Total Chaos" of his current mental state and the void left behind when love is replaced by a diagnosis.

I Built a Cyberpunk Terminal Portfolio with Next.js, Antigravity and Gemini AI

Malawige Inusha Thathsara Gunasekara — Fri, 16 Jan 2026 19:16:04 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

I’m Inusha Gunasekara, an IT undergraduate at the University of Moratuwa, Sri Lanka, and the co-founder of Tekkeys, where we're building agentic AI tools.

For this challenge, I didn’t want to build just another "landing page." I wanted to build a Digital Twin. I conceptualized "System 1"—a sentient, terminal-based operating system that represents my skills, projects, and personality as code. The goal was to create an interface that feels alive, combining the raw utility of a CLI with the polished aesthetics of a cyberpunk interface.

I initially engineered the system as a fully autonomous clone powered by the Gemini 2.5 Flash-Lite API. However, to guarantee 100% uptime and zero latency for public access, I pivoted the architecture to a deterministic "Simulation Mode." This hybrid approach preserves the sentient "vibe" of the AI while ensuring the reliability required for a production-grade portfolio.

Portfolio

https://inusha-portfolio-326006174526.us-central1.run.app

(Type "help" to see available commands, or try "projects" to see what I'm working on.)

How I Built It

My portfolio is a Stateless Terminal built for extreme performance, security, and zero-cost scaling.

The Tech Stack:

Framework: Next.js 16 (App Router) for the core React architecture.
Styling: Tailwind CSS v4 for the utility-first, cyberpunk aesthetic.
Infrastructure: Google Cloud Run (Serverless) for scalable, containerized deployment.
Containerization: Docker (Multi-stage build) using the standalone output mode.

The "Digital Twin" Architecture:
The core of this project is "System 1"—a digital representation of my persona.

Initial Prototype: I originally built a fully autonomous agent using the Gemini 2.5 Flash-Lite API. While powerful, I identified that relying on a metered API for a high-traffic public landing page introduced potential latency and quota risks ("The Reddit Hug of Death").
Production Optimization: To ensure a production-grade user experience, I engineered a Deterministic Simulation Engine. This engine mimics the streaming "typing effect" of an LLM but pulls from an optimized, local knowledge graph. This decision reduced API latency from ~400ms to <5ms and eliminated all running costs, while preserving the "sentient" feel of the terminal.

Deploying to Google Cloud Run:
I chose Cloud Run for its "Scale to Zero" capability. By using a multi-stage Dockerfile, I reduced the final container size by approximately 80%. This ensures the portfolio spins up instantly when a user visits but costs $0 when idle.

What I'm Most Proud Of

1. The "Halt Sequence" (`sudo delete`)

I wanted the terminal to feel like a real, vulnerable operating system, not just a read-only website. I implemented a hidden "kill switch" where users can type sudo delete followed by confirm. This triggers a dramatic, system-wide crash simulation—turning the screen black and forcing a "reboot" sequence. It adds a layer of gamification that encourages users to explore the boundaries of the interface.

2. Engineering the "Simulation Engine"

While it was tempting to keep the live Gemini API connection, I am most proud of the decision to build a Deterministic Simulation Engine. I realized that for a portfolio, reliability is a feature. By architecting a local "mock stream" that replicates the exact typing patterns and latency of an LLM, I achieved the "sentient AI" feel without the risk of API quotas or network latency. It taught me that sometimes the best engineering solution is removing a dependency, not adding one.

3. Secure Live Data (Gas Tracker)

I built a real-time Ethereum Gas Tracker that fetches live data from Etherscan. Instead of exposing my API keys on the client side, I built a secure Next.js Server-Side Proxy. This route acts as a gateway, injecting the secrets on the server before forwarding the request to Etherscan.

4. The "Cyberpunk" Polish

I spent significant effort fine-tuning the visual details. Balancing these high-fidelity "glitch" effects with the performance requirements of a web app (using Tailwind CSS v4) was a rewarding challenge in frontend optimization.

Check The portfolio live in action: https://inusha-portfolio-326006174526.us-central1.run.app

The Features I Killed to Ship "The 80%" App in 4 Weeks

Malawige Inusha Thathsara Gunasekara — Mon, 12 Jan 2026 15:02:41 +0000

I almost fell into a trap believing that "more features" equals a "better product." When I started building The 80%, an assistant tool which helps students to keep track of their attendance, medicals and GPA. I had a strict four-week deadline to ship a production-ready attendance tracker. I quickly realized that if I tried to build everything I wanted, I would never ship what the user needed. Then I remembered what Elon Musk said, "The Best Part is No Part." I didn't just cut features to save time; I cut them to save the architecture from unnecessary complexity.

Here are the five worth-mentioning features I killed in The 80%.

1. The Backup Server Trap

I wasted the first few days being obsessed with 100% uptime. I wanted to build a secondary failover server just in case Firebase went down. I realized I was solving an imaginary problem. Firebase has 99.99% uptime, while the probability of my users having poor campus Wi-Fi is high. The real risk wasn't Google servers failing. It was the connection dropping between the classroom and the cloud. I abandoned the backup server entirely and embraced an Offline-First Architecture using Hive. By treating the user's device as the primary data source, the app works perfectly regardless of server status, I learned that I shouldn't build complex distributed systems when a local database solves the actual problem.

2. The Medical Cloud Storage Nightmare

I planned to add a feature allowing students to upload photos of their medical certificates to the cloud so they would never lose them. But as I designed it, two major problems appeared: the extreme cost of storing images for thousands of users on the Firebase Free Tier, and the liability of holding Personally Identifiable Information (PII). If I held medical records, I was responsible for protecting them from data breaches. As a student developer, I didn't want the risk of a data breach hanging over my head. To solve this, I built the "The Local Wallet." within the app itself. Instead of uploading files, the app simply saves the images in the device's local sandbox and stores a link to the file path. The data stays 100% on the user's phone, resulting in zero cloud costs and zero privacy liability. I learned that the most secure data is the data you never collect.

3. The "Automated Email" Fantasy

I wanted to build a productivity hack where the app would automatically send official emails from the student's university account using SMTP or OAuth. It sounded like a great productivity hack until I looked at the technical reality. University firewalls and Multi-Factor Authentication (MFA) makes this feature hard to implement. Making it work I had two bad choices.

Requesting Credentials from the User: Asking users for their university passwords which leads to a a massive security violation that looks exactly like phishing. or
Enterprise Verification: I would have to navigate the university's bureaucracy to get official OAuth approval. I avoided this method in order to reduce the complexity of the app. I killed this automation entirely and stuck with the traditional email flow. The app automatically opens the default email app, then the user can send the drafted email with the medical report. I learned two major lessons here. First one is "Trust is harder to build than a feature." And as developers we shouldn't compromise security for a "cool" automation.

4. All University Supported Grading System

I had a plan to create a database containing the grading scales for all major universities all around the world to automate the GPA calculation process. But I quickly realized that this needs constant maintainability, which I don't have time to do as a undergraduate. It would require weeks of manual data entry and maintenance, and if a university changed their grading policy, my app would be instantly outdated. It simply wasn't worth the effort for my app. Instead, I built a feature that allows the user to configure their own grading scale. This taught me that when shipping, flexibility is often better than hard-coded perfection.

5. Sync Custom Profile Picture Across Devices

I wanted users to be able to pick a photo from their gallery and have that custom profile picture sync across all their devices via Firebase. This led me to the "Cost" problem again. I would need a paid Firebase plan to store these custom images, or I would have to bloat the database by storing base64 strings, which requires unnecessary processing power and time. I compromised by removing the ability to upload custom photos and instead provided a set of high-quality, pre-defined 3D avatars. I only sync the Avatar ID (a simple integer) across devices, keeping the data transfer minimal. This was a valuable lesson in distinguishing between what is needed (identifying users) versus what is wanted (full customizability).

Conclusion

It is easy to add features. It is hard to remove them. By killing these features, I didn't just save time; I built a product that is faster, cheaper to run, and more secure. I learned that my job isn't to build the most complex version of an idea, but to ship the version that actually works. The 80% proved to me that sometimes, the best code is the code you delete.

🔗 Explore the Project

📂 GitHub Repository: View the demo code and releases
📝 Project Documentation: Read the Notion Docs

Building AI Agents: Concepts & Architecture

Malawige Inusha Thathsara Gunasekara — Wed, 07 Jan 2026 15:11:40 +0000

If you look past the hype cycle, AI Agents represent a fundamental shift in how we write software. We are moving from defining how a task is done (traditional automation) to defining what the goal is and letting the system figure out the rest.

This article breaks down the conceptual architecture of AI agents, how they differ from standard automation, and the memory systems required to make them actually useful.

The Core Definition: What is an Agent?

An AI Agent is a computational entity that acts independently on a user's behalf. Unlike a standard script that executes a rigid sequence of commands, an agent creates its own plan.

To be considered "Agentic," a system generally needs these characteristics:

Reflective: It learns from previous steps (loops back to correct errors).
Autonomous: It executes without manual hand-holding after the initial prompt.
Reactive: It responds to environmental changes (e.g. an API failure or new data).
Proactive: It can schedule actions based on recognized patterns.

The Paradigm Shift: Automation vs. Agentic Systems

As developers, we are used to Deterministic Execution.

Traditional Automation: Input ---> Process A ---> Process B ---> Output. If the input is unstructured or ambiguous, the pipeline breaks. It relies on fixed decision trees.
Agentic Systems: Non-Deterministic Execution. The agent receives an ambiguous goal (e.g. "Plan a trip to Tokyo based on my emails"). It uses an LLM to reason about the request, decomposes it into sub-tasks, and decides which tools to call.

The Reality Check: The critical difference is the ability to handle "fuzzy" inputs. Agents thrive where drop-down menus fail.

The Agent Architecture

A functional agent consists of four core components. Think of this as the anatomy of the system:

Perception: How the agent "sees" (Text, Audio, Images).
Planning (The Brain): The LLM. This handles reasoning, reflection, and task decomposition.
Tools (The Hands): Python functions, APIs, or Microservices. The agent doesn't "know" how to search the web; it "knows" it has a tool called search_web() and decides when to invoke it.
Memory: The context and state storage.

Deep Dive: Memory Systems

Most developers stop at "Context Window" (Short-term memory), but robust agents require a memory architecture inspired by human cognition.

Memory Type	Human Parallel	AI Implementation
Short-term	Remembering a phone number for 12s.	Context Window: Limited by token counts (OpenAI/Anthropic). Enhanced via caching.
Long-term	Knowledge retained for years (e.g. specialized skills).	RAG (Retrieval-Augmented Generation): Vector databases (like MongoDB) storing domain-specific docs.
Working	Processing new info during a conversation.	Hybrid RAG: Combining real-time internet search (e.g. Tavily) with stored knowledge.
Episodic	Remembering specific past events.	Interaction Logs: Storing user specific past sessions to recall context later.
Semantic	Memories triggered by meaning (rose = love).	Semantic Cache: Retrieving similar past queries to save API costs and speed up responses.

The Tech Stack for Memory:

Modern stacks often use a unified database (like MongoDB) to handle both operational metadata (JSON) and vector embeddings. This avoids the "synchronization hell" of trying to keep a SQL database in sync with a separate Vector DB like Pinecone.

The RAG Pipeline (Retrieval Architecture)

If the Agent is the brain, RAG is the library it references. A standard pipeline involves:

Data Prep: Cleaning, anomaly detection, and "chunking" data (breaking text into embedding-suitable segments).
Ingestion: Passing chunks through an embedding model to get vectors, stored in your DB.
Retrieval: The agent converts a user query into a vector, performs a Vector Search (semantic similarity) or Hybrid Search (keyword + semantic), and feeds the relevant chunks to the LLM.

A Framework for Building

Don't open your IDE yet. The biggest mistake developers make is jumping into code without mapping the reasoning flow.

Level 0: The Paper Phase

Map the manual process step-by-step.
Identify which steps are computational (calculating a sum) vs. reasoning (deciding if a tone is rude).
Determine where you need a human-in-the-loop for reliability.

Level 1: The Prototype

Single Agent, Single Tool.
Use a notebook. Do not overengineer a multi-agent swarm for a simple task.

Level 2: The MVP

Connect 3 functions/tools to 1 agent.
Focus on the problem, not the technology. Ask: "Does this actually save time, or is it just cool?"

Conclusion

Building agents is less about prompt engineering and more about systems engineering. It requires managing state, designing robust tools, and structuring memory effectively.

How I Built a Flutter + Gemini AI App to "Hack" My University Attendance (Open Source)

Malawige Inusha Thathsara Gunasekara — Sat, 03 Jan 2026 17:59:33 +0000

The Problem: The "80% Anxiety"

If you are an engineering student (like me at the University of Moratuwa), you know the terror of the 80% Rule.

It’s simple math: Attend 80% of classes or get banned from the exam.

But in reality, it’s a nightmare.

"If I skip today's lecture, does my percentage drop to 79.9%?"
"Did the lecturer count that medical leave?"
"Can I afford to sleep in tomorrow?"

I found myself doing complex algebra at 2 AM just to decide if I could skip a morning lecture. I needed a tool that didn't just "track" habits, but actually strategized for me.

So, I built The 80 Percent.

Here is how I engineered the fullstack software using Flutter, Google Gemini AI, and a heavily optimized Firebase backend, all while staying on the Free Tier.

1. The Strategy Engine: "Safe to Skip" Logic

Most habit trackers just say "You are at 75%." That’s useless information. I needed actionable advice.

I wrote a custom algorithm that looks at the future remaining sessions of the semester to calculate a "Safety Margin."

The "Buffer" Formula

If you are above your target, how many classes can you miss before you hit the danger zone?

I implemented this formula in Dart:

Dart

// The Magic Formula
int calculateSafeSkips(int present, int total, double target) {
  // Formula: Floor( (Present / Target) - Total )
  int skips = ((present / target) - total).floor();
  return skips < 0 ? 0 : skips;
}

Scenario: You attended 18/20 classes. Target is 80%.
Result: You can safely skip 2 more classes.
Why it matters: It stops students from panic-attending classes they don't need to, preventing burnout.

The "Recovery" Formula

If you are failing, how many classes must you attend in a row to survive?

Dart

// The Recovery Formula
int calculateRecovery(int present, int total, double target) {
   // Formula: Ceil( (Target * Total - Present) / (1 - Target) )
   return ((target * total - present) / (1 - target)).ceil();
}

This was critical because a student at 70% needs to know exactly when they will be safe again.

2. The AI Challenge: Parsing Timetables with Gemini 2.5

The biggest friction in any student app is Setup. Nobody wants to manually type in 15 modules and timeslots.

I wanted a feature where a user could upload their official PDF/image timetable, and the app would set itself up instantly.

Why Gemini 2.5 Flash?

I chose Google's Gemini 2.5 Flash because:

Speed & Cost: It is the current standard for high-speed, low-cost inference, perfect for a free student app.
Multimodal Intelligence: It accepts PDF/Image inputs directly.
Zero-Shot Capability: Unlike older models that needed endless examples, 2.5 Flash is smart enough to extract complex grid data with just a single, well-structured system instruction.

The Implementation

Instead of wasting tokens on "few-shot" examples, I used a System Instruction approach. I defined the exact JSON schema in the prompt and let the model do the heavy lifting.

Dart

// Actual Code from the App
final model = GenerativeModel(
  model: 'gemini-2.5-flash', 
  apiKey: apiKey
);

final prompt = """
You are an intelligent assistant that extracts university timetable data.
**GOAL**: Extract timetable metadata, modules, and classes into structured JSON.
**SCHEMA**:
{
  "modules": [{"code":String, "name":String...}],
  "classes": [{"day":String, "time":String, "location":String...}]
}
""";

final response = await model.generateContent([
  Content.text(prompt),
  Content.data('image/png', timetableImageBytes)
]);

The app parses the JSON response and batch-writes the classes to the local database. This "Zero-Shot" approach keeps the request payload small and fast.

3. The Architecture: Surviving the Firebase Free Tier

As a student, I have $0 budget.

Firebase is great, but the Firestore limits (50,000 reads/day) are a trap. If I have 500 users and they open the app 10 times a day, fetching 10 records each... that’s 50,000 reads. Quota exceeded on Day 1.

My "Offline-First" Solution

I designed the app to be Offline-First using a Repository Pattern.

Local Caching: When a user opens the app, it loads data from the local cache instantly.
Lazy Syncing: It only writes to Firestore when the user explicitly changes something (Marking Attendance).
No Images in DB: I initially wanted to sync profile pictures, but storing images requires the "Blaze" (Paid) plan or Base64 hacks that bloat document size. I cut this feature to ensure the app stays 100% free and fast.

This architecture means I can scale to thousands of users without paying a cent.

4. The Result: A Production-Ready Beta

"The 80%" isn't just a calculator; it's a full-stack academic tool.

Tech Stack: Flutter, Firebase Auth/Firestore, Provider, Gemini API.
Status: Open Source & Beta Live.

Building this taught me that Engineering is about tradeoffs. I had to trade fancy features (cloud images) for stability (free tier limits), and I had to trade simple logic for complex math to make the app actually useful.

Try it out

I’m looking for feedback from fellow developers and students.

Check out the ecosystem:
👉 Notion Documentation
👉 Demo code and APK file

(Star the repo if you think the project is cool! ⭐)

The AI Filmmaking Pipeline: Directing Without a Camera

Malawige Inusha Thathsara Gunasekara — Sat, 03 Jan 2026 16:48:45 +0000

As IT students, we are used to pipelines: CI/CD, data processing, rendering. Surprisingly, modern filmmaking is evolving into just another computational pipeline. Here is the no-nonsense guide to the tools and logic you need to replace a film crew with a GPU.

1. Pre-Production: The Logic Layer

Before generating pixels, you need to generate structure. This phase is about planning and visualization essentially the "architecture design" of your film.

Brainstorming & Scripting: Don't stare at a blank page. Use Claude for brainstorming concepts and ChatGPT to structure the actual script and treatment.
The Framework: The session introduced a structured approach to story generation that feels very similar to debugging:
- Objective (Why?): What is the core message?
- Idea (What?): The plot points.
- Story (How?): The narrative structure. ## 2. Production: The Generative Engine

This is where the heavy lifting happens. We are swapping cameras for diffusion models.

The Stack

Midjourney: For generating high-fidelity static shots and storyboards.
Google VEO 3: The heavy hitter for realistic video generation.
Kling AI & Krea AI: For converting static images into motion (Image-to-Video). ### The "Master Prompt" Algorithm

For developers, this is the most valuable takeaway. You don't just type "cool scene." You use a parameterized function.

The Formula: [Emotional tone] + [Visual reference] + [Subject] + [Composition] + [Lighting] + [Camera settings]

Example Code: [Royal, epic, ancient] meets [Lord of the Rings, 300] of [Krishna speaking with Pandavas] inside [Hastinapur palace] shot on [IMAX film camera]

3. Post-Production: The Audio-Visual Merge

Raw video is silent. To sell the illusion, you need the "audio stack."

Music: Suno generates original soundtracks based on mood prompts.
Voice: ElevenLabs handles realistic voiceovers and cloning, removing the need for actors.
Assembly: Bring it all together in CapCut or DaVinci Resolve. ## Summary: The New Workflow

The workflow has shifted from capture to synthesis:

Ideate with LLMs (Claude/Gemini).
Generate assets with Diffusion models (Midjourney/VEO).
Animate with Motion models (Kling).
Synthesize audio (Suno/ElevenLabs).

Bitcoin 101: From Barter to Blockchain

Malawige Inusha Thathsara Gunasekara — Thu, 01 Jan 2026 13:44:48 +0000

Money has evolved significantly over human history. We started with the barter system, trading goods directly, which was inefficient. We moved to commodity money like gold and salt, then to fiat money (USD, EUR) backed by governments, and eventually to digital banking.

But in 2009, Bitcoin emerged as the first decentralized, borderless, and scarce digital currency, removing the need for central authorities.

In this article, we’ll break down the technical fundamentals of Bitcoin, from the whitepaper to the architecture of a block.

The Vision: The 2008 Whitepaper

Satoshi Nakamoto’s whitepaper introduced a peer-to-peer digital currency that solved the double-spending problem using Proof-of-Work (PoW).

Core Principles

Fixed Supply: There will never be more than 21 million BTC.
Decentralization: No single authority controls the network.
Immutability: Once a transaction is on the blockchain ledger, it cannot be altered.
Censorship Resistance: Anyone can transact; no one can be blocked.

Under the Hood: Block Architecture

A blockchain is essentially a timestamped chain of blocks. Think of a block like a "page" in a ledger.

Structure of a Block

Every block contains three main components:

Block Header: Metadata about the block.
Transaction Counter: The number of transactions included.
Transactions: The actual list of payments.

The Block Header

The header is critical for mining and validation. It includes:

Version: The rules the block follows.
Previous Block Hash: The link to the previous block (creating the "chain").
Merkle Root: A summary of all transactions.
Timestamp: When the block was mined.
Difficulty Target (nBits): Defines how hard it is to mine the block.
Nonce: The variable number miners change to solve the cryptographic puzzle.

Data Structures: Merkle Trees & Roots

Bitcoin uses Merkle Trees (a type of binary tree) to verify data efficiently.

The Merkle Tree: Hashes every transaction, pairs them up, and hashes them again until only one hash remains.
The Merkle Root: This single "root" hash acts as a fingerprint for the entire block.

Why is this useful? It allows for Simplified Payment Verification (SPV). A user can verify a specific transaction existed without downloading the entire blockchain history. If even one bit of a transaction changes, the Merkle Root changes completely.

Consensus: Proof-of-Work (PoW)

How does the network agree on the truth? Through mining.

Miners collect transactions.
They compete to solve a cryptographic puzzle by adjusting the Nonce.
The winner gets the block reward (new BTC + transaction fees).

While secure and decentralized, PoW is energy-intensive and has limited scalability.

Scaling & Evolution

The Rise of Altcoins

Following Bitcoin, "1st Gen" altcoins emerged. Most were forks of Bitcoin with minor tweaks:

Litecoin: Faster block times.
Namecoin: Decentralized DNS.
Ethereum: Eventually introduced smart contracts, moving beyond simple currency.

The Lightning Network (Layer 2)

Bitcoin processes only ~7 transactions per second. To solve this, the Lightning Network was built as a Layer 2 solution.

How it works: Users open payment channels and transact off-chain instantly and cheaply.
Settlement: Only the final balances are recorded on the main blockchain.

This enables fast micropayments, though it comes with challenges like routing complexity and liquidity constraints.

Conclusion

Bitcoin revolutionized money by combining cryptography, game theory, and distributed systems. Understanding these fundamentals—Merkle trees, block headers, and consensus mechanisms—is the first step to mastering the wider Web3 landscape.

DEV Community: Malawige Inusha Thathsara Gunasekara

Reverse-Engineering an Old Node.js Crossword App into a Modern Next.js Stack

The Teardown: Reverse-Engineering the Core Loop

Accelerating the UI with v0

The Modern Stack & Architecture

1. Deterministic Puzzle Generation

2. Smart Autosave & The Visibility API

3. Data Integrity: The "No Double-Credit" Problem

Final Thoughts

Stop Funding History: Building a Demand Prediction App to Optimize Trade Spend

The "Empty Shelf" Problem (Right-Censoring)

Mapping the Real World (Spatial Features)

Squeezing Every Drop of Budget (The Optimizer)

Building Trust with the Field App

The Dirty Reality of Data

I Made Tyre Size Detection App Using Gemma4:e4b

What I Built

The Problem

The Solution

Demo

Code

How I Used Gemma 4

Built an AI Study Tool That Refuses to Give You the Answers for UoM

The Community

What I Built

Demo

Code

How I Built It

How I Built a 15,000+ Line Flutter App with Gemini to "Hack" My University Attendance

What I Built with Google Gemini

Demo

What I Learned

Google Gemini Feedback

The Shores of Denial – The World that Shouldn't Exist

My Voluntary Descent

Navigating a Broken Mind

The Realization of the Mission

I Built a Cyberpunk Terminal Portfolio with Next.js, Antigravity and Gemini AI

Portfolio

How I Built It

What I'm Most Proud Of

1. The "Halt Sequence" (sudo delete)

2. Engineering the "Simulation Engine"

3. Secure Live Data (Gas Tracker)

4. The "Cyberpunk" Polish

The Features I Killed to Ship "The 80%" App in 4 Weeks

1. The Backup Server Trap

2. The Medical Cloud Storage Nightmare

3. The "Automated Email" Fantasy

4. All University Supported Grading System

5. Sync Custom Profile Picture Across Devices

Conclusion

🔗 Explore the Project

Building AI Agents: Concepts & Architecture

The Core Definition: What is an Agent?

The Paradigm Shift: Automation vs. Agentic Systems

The Agent Architecture

Deep Dive: Memory Systems

The RAG Pipeline (Retrieval Architecture)

A Framework for Building

Conclusion

How I Built a Flutter + Gemini AI App to "Hack" My University Attendance (Open Source)

The Problem: The "80% Anxiety"

1. The Strategy Engine: "Safe to Skip" Logic

The "Buffer" Formula

The "Recovery" Formula

2. The AI Challenge: Parsing Timetables with Gemini 2.5

Why Gemini 2.5 Flash?

The Implementation

3. The Architecture: Surviving the Firebase Free Tier

My "Offline-First" Solution

4. The Result: A Production-Ready Beta

Try it out

The AI Filmmaking Pipeline: Directing Without a Camera

1. Pre-Production: The Logic Layer

The Stack

3. Post-Production: The Audio-Visual Merge

Bitcoin 101: From Barter to Blockchain

The Vision: The 2008 Whitepaper

Core Principles

1. The "Halt Sequence" (`sudo delete`)