https://nabil-thange.vercel.app/blog Full-stack developer and AI engineer from Mumbai, India. Sharing insights on web development, AI integration, hackathons, and building products that matter. en-IN Sun, 01 Feb 2026 00:00:00 GMT Wed, 01 Jul 2026 21:55:25 GMT 3600 thangenabil@gmail.com (Nabil Salim Thange) thangenabil@gmail.com (Nabil Salim Thange) Copyright 2026 Nabil Salim Thange. All rights reserved. https://nabil-thange.vercel.app/og-image.png https://nabil-thange.vercel.app 144 144 https://nabil-thange.vercel.app/blog/freelance-developer-rates-mumbai-2026 https://nabil-thange.vercel.app/blog/freelance-developer-rates-mumbai-2026 Transparent breakdown of freelance developer rates in Mumbai, India. Learn what to expect when hiring or pricing your services as a freelance developer. Sun, 01 Feb 2026 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) Freelance Mumbai Rates Hiring Guide https://nabil-thange.vercel.app/blog/how-to-hire-freelance-developer-india https://nabil-thange.vercel.app/blog/how-to-hire-freelance-developer-india Step-by-step guide to finding, vetting, and hiring freelance developers in India. Avoid common pitfalls and build successful partnerships. Sun, 01 Feb 2026 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) Hiring Guide Freelance India Best Practices https://nabil-thange.vercel.app/blog/future-of-ai-access-privilege https://nabil-thange.vercel.app/blog/future-of-ai-access-privilege As a Mumbai-based AI developer, I explore how restricted AI access and rising costs could reshape software development for freelancers and startups. Thu, 01 Jan 2026 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) AI Future of Tech Software Development Opinion https://nabil-thange.vercel.app/blog/building-ai-agents-with-memory https://nabil-thange.vercel.app/blog/building-ai-agents-with-memory Technical deep-dive into the memory architectures I use for production AI agents, from browser automation to multi-step workflows. ; }; output: { result: string; confidence: number; metadata: Record; }; parentStep: string | null; createdAt: Date; } ``` ### Why Parent Relationships Matter The `parentStep` field is crucial—it builds a **tree of execution**, not just a flat sequence. **Benefits:** - Retry tracking - Branch history - Error debugging - Workflow visualization - State recovery This saved me countless hours debugging NbAIl's voice command chains. ### Production Benefits | Without Checkpoints | With Checkpoints | |---------------------|------------------| | Entire workflow restarts | Resume instantly | | Lost progress | Persistent state | | Difficult debugging | Complete execution history | | Higher API costs | Minimal recomputation | In production, I create: - One checkpoint **before** every LLM call - One checkpoint **after** every action The database writes are cheap compared to rerunning complex workflows. --- ## Pattern 2: Vector Stores for Long-Term Memory Checkpointing solves **task memory**. It doesn't solve **knowledge memory**. Agents also need to remember things across entirely different sessions. **Examples:** - User preferences - Writing styles - Business rules - Past conversations This is where vector databases become essential. ### My Implementation with Embeddings ```typescript import { OpenAIEmbeddings } from '@langchain/openai'; import { PineconeStore } from '@langchain/pinecone'; const embeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" }); const vectorStore = await PineconeStore.fromExistingIndex( embeddings, { pineconeIndex: "agent-memory" } ); ``` **When a preference becomes known:** ``` "User prefers brutalist design with dark themes" ``` Store it as an embedding. **Later, when generating a new template:** ``` "What design style does this user prefer?" ``` Similarity search retrieves only relevant memories. No massive prompt required. ### Store Only Valuable Memories **I prioritize storing:** - Permanent preferences - Reusable facts - Successful strategies - User profiles **I skip:** - Temporary thoughts - Intermediate reasoning - One-time observations Filtering during writing is cheaper than filtering during retrieval. --- ## Pattern 3: Hybrid Memory Architecture (My Production Standard) The most reliable architecture combines both approaches. ### Short-Term Memory (Checkpoints) **Stored in:** PostgreSQL/Supabase **Responsible for:** - Current workflow state - Tool outputs - Progress tracking - Error recovery ### Long-Term Memory (Vector Store) **Stored in:** Pinecone/Chroma **Responsible for:** - User preferences - Historical knowledge - Business context - Reusable patterns ### Combined Workflow 1. Load checkpoint → recover workflow state 2. Query vector database → get relevant context 3. Build focused prompt 4. Execute LLM 5. Save checkpoint 6. Store new knowledge (if valuable) This keeps prompts focused while allowing continuous learning. **I use this exact pattern in my production AI projects.** --- ## My Production Best Practices ### 1. Separate Memory Types Never mix: - Workflow state (checkpoints) - Semantic memory (vectors) - Conversation history (cache) Each serves a different purpose. ### 2. Checkpoint Frequently I checkpoint after every: - LLM response - Tool call - API request - State change Frequent persistence = faster recovery. ### 3. Keep Retrieval Focused Retrieving 5 relevant memories beats injecting 500 previous interactions. **Quality > Quantity.** ### 4. Optimize Storage Costs - Structured databases for transactional data - Vector databases for semantic retrieval - File storage for large artifacts Choosing the right storage keeps infrastructure efficient. ### 5. Design for Failure My rule: **Assume interruptions will happen.** Every agent I build can resume from any checkpoint without losing progress. --- ## Real-World Impact Organizations adopting layered memory architectures typically see: - ✅ Higher workflow completion rates - ✅ 40-60% lower API costs - ✅ Faster recovery after failures - ✅ Better user personalization - ✅ Easier debugging - ✅ More scalable autonomous agents **Reliable memory transforms AI from prototype to production.** --- ## Tech Stack I Recommend Based on my experience building multiple AI agents: **For Checkpointing:** - PostgreSQL (Supabase for serverless) - Redis (for fast session recovery) - SQLite (for local/embedded agents) **For Vector Memory:** - Pinecone (managed, easy to scale) - Chroma (open-source, self-hosted) - Weaviate (advanced semantic search) **For Orchestration:** - LangChain (comprehensive framework) - LangGraph (for complex workflows) - Custom Node.js/Python (for specific use cases) --- ## Lessons from Building NbAIl My HackHazards 2025 winning project taught me that: 1. **Speed matters more than perfection** → Used Groq for ultra-fast responses instead of the "best" model 2. **Memory architecture beats model size** → Checkpointing made NbAIl resume voice commands seamlessly 3. **User experience trumps technical complexity** → Three.js animations + reliable memory = better than complex AI with no memory The judges didn't care about my LLM choice. They cared that the demo **worked reliably every time**. --- ## FAQ ### Why can't AI agents use larger context windows? Larger contexts increase costs, slow inference, and reduce focus. Structured memory retrieval is more efficient. ### What is checkpointing? Storing workflow progress after important actions, allowing agents to resume instead of restart. ### Should every observation be stored? No. Store only reusable knowledge: preferences, decisions, long-term facts. ### Can this reduce API costs? Yes. By retrieving only relevant context, you significantly lower token usage. ### What tools do you use? - **Embeddings:** text-embedding-3-small - **Vector DB:** Pinecone - **Framework:** LangChain - **Database:** Supabase (PostgreSQL) --- ## Conclusion Building AI agents that remember isn't about increasing model size or expanding prompts endlessly. It's about designing a memory system that separates: - **Short-term execution state** (checkpoints) - **Long-term knowledge** (vector stores) By combining structured checkpoint logs with semantic retrieval, you create agents that: - Recover from failures - Personalize interactions - Scale to thousands of tasks - Keep costs under control Whether you're building browser automation, voice assistants, or autonomous workflows, investing in memory architecture from day one pays dividends as systems grow. **This is how I build production AI agents in Mumbai that compete globally.** --- **About This Post:** Technical insights from Nabil Thange, full-stack developer and AI specialist based in Mumbai. Check out [NbAIl](https://github.com/NabilThange) (HackHazards 2025 Winner) and connect on [LinkedIn](https://www.linkedin.com/in/nabil-thange/). **Building AI agents?** Let's discuss memory architectures—reach out on [Twitter/X](https://x.com/THEONLYNABIL) or [email me](/contact). ]]> Thu, 01 Jan 2026 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) AI Technical Architecture LangChain https://nabil-thange.vercel.app/blog/building-ai-that-doesnt-suck https://nabil-thange.vercel.app/blog/building-ai-that-doesnt-suck Most AI applications feel like tech demos. I explore what it takes to build AI-powered tools that people actually want to use daily. Sun, 01 Dec 2024 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) AI Product Development UX Design https://nabil-thange.vercel.app/blog/the-commerce-kids-guide-to-tech https://nabil-thange.vercel.app/blog/the-commerce-kids-guide-to-tech My unconventional journey from balance sheets to code. Why starting late in tech is actually an advantage. Cool Tech Commerce students learn to start with the customer and work backward. We ask: "What problem are we solving, and will people pay for it?" This mindset helped me avoid the trap most developers fall into: **building impressive tech that nobody needs**. ### 3. Resource Constraints Business students learn to maximize ROI. In tech, this means: - Choosing the right tools (not the newest) - Building MVPs that ship - Validating before scaling ## The Self-Taught Advantage Being self-taught forced me to develop meta-skills: ### Learning How to Learn I didn't have a structured curriculum. I had to: - Identify knowledge gaps - Find quality resources - Build projects to validate learning - Teach myself to stay motivated These skills matter more than knowing React. ### Building in Public Without a CS degree to showcase, I had to prove myself through projects: - Gitskinz: 60+ templates, used globally - NbAIl: HackHazards 2025 winner - NutriSnap: First app with proper Indian food support - Shopwiz: Conversational AI shopping assistant Each project solved a real problem for real users. ### Connecting the Dots My commerce background helps me understand: - **Why** a startup needs a product - **How** to monetize effectively - **When** to pivot or persist Combined with technical skills, this makes me a stronger builder. ## From Mumbai with Perspective Starting in Mumbai's tech ecosystem—away from the Silicon Valley echo chamber—taught me that: **Not everyone's problem looks like a San Francisco tech worker's problem.** This is why NutriSnap includes Indian food (most nutrition apps don't). This is why I think about internet costs when building apps. This is why I focus on problems that matter. ## What I Learned the Hard Way ### 1. Imposter Syndrome is Universal Every developer feels it. CS degree or not. The difference? I learned to **focus on shipping** instead of credentials. ### 2. Certifications Matter Less Than Projects My ISRO ML certification opened doors. But you know what opened more? Having live projects that solve real problems. ### 3. Community is Everything The developer community in Mumbai, online communities, and hackathons taught me more than any course. Winning HackHazards 2025 validated that unconventional paths work. ## Advice for Late Starters ### Start Building Today Don't wait until you "know enough." I started building when I barely understood JavaScript. You learn by doing. ### Pick a Real Problem Find something that frustrates you daily. Build a solution. Even if it's ugly, if it works, you've created value. ### Document Your Journey I wish I'd started blogging earlier. Your struggles help others. Your successes inspire beginners. Your failures teach lessons. ### Leverage Your Background Your non-tech background is an **advantage**, not a liability. You see problems others miss. You ask questions others don't think to ask. ## The Mumbai Advantage Being based in Mumbai (specifically Kharghar, Navi Mumbai) means: - Lower cost of living = more runway to experiment - Diverse problem spaces = unique product opportunities - Global mindset + local context = better products ## Where I Am Now - **Full-stack developer** specializing in React, Next.js, and AI - **ISRO-certified** in machine learning - **Microsoft-certified** SQL developer - **Hackathon winner** (HackHazards 2025) - **Founder** of Gitskinz And I'm just getting started. ## The Real Secret Starting late in tech isn't a disadvantage. It's a **different starting point** with unique advantages: - More life experience - Better understanding of user problems - Stronger work ethic (you chose this) - Clearer sense of purpose ## Your Turn If you're a late starter, remember: 1. Your background is an asset 2. Self-teaching builds valuable meta-skills 3. Projects matter more than credentials 4. Community accelerates learning 5. Ship early and often The best time to start was yesterday. The second-best time is now. --- **From Kharghar, Mumbai to the world.** If a commerce kid can become a developer, so can you. ]]> Fri, 01 Nov 2024 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) Career Learning Self-Taught https://nabil-thange.vercel.app/blog/hackathons-speed-running-product-development https://nabil-thange.vercel.app/blog/hackathons-speed-running-product-development What I learned from winning multiple hackathons. A playbook for learning to build fast, validate quickly, and iterate ruthlessly. Tue, 01 Oct 2024 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) Hackathons Product Development Learning https://nabil-thange.vercel.app/blog/why-i-built-gitskinz https://nabil-thange.vercel.app/blog/why-i-built-gitskinz The story behind creating a GitHub profile generator used by developers worldwide. Why the best way to learn is to solve your own problems publicly. Product Having 60 templates means nothing if nobody knows about it. I: - Shared on Twitter weekly - Posted in Reddit communities - Asked users to share - Added "Powered by Gitskinz" links **Result:** Organic growth through word-of-mouth. ### 4. Make It Free Gitskinz is 100% free. No paywalls, no freemium model, no ads. Why? Because: - Students can't afford subscriptions - Free tools get shared more - I wanted to help the community - Not everything needs to be monetized ### 5. Design Matters Developers claim they don't care about design. They're lying. The brutalist aesthetic made Gitskinz stand out. People shared it because it looked cool, not just because it was useful. ## The Mumbai Perspective Building from Kharghar, Navi Mumbai gave me advantages: ### Low Competition Most developer tools are built in Silicon Valley, optimized for Silicon Valley problems. Gitskinz fills a gap others weren't addressing. ### Global Mindset Being in India means thinking globally from day one. Gitskinz works for developers everywhere, not just one market. ### Cost Advantage Low living costs meant I could afford to build Gitskinz for free without worrying about immediate monetization. ## Impact I Didn't Expect Gitskinz has been used by: - Bootcamp graduates landing their first jobs - Self-taught devs building their brand - Experienced devs refreshing their profiles - Students impressing recruiters The coolest part? **Seeing Gitskinz profiles in the wild.** People tag me when they use a template. Some have gotten jobs because recruiters noticed their profiles. That's the real reward. ## What I'd Do Differently ### 1. Add Analytics Earlier I waited 2 months to add basic analytics. Should've done it day one to understand user behavior. ### 2. Build Community Faster Users wanted to share templates. I should've added user submissions earlier. ### 3. SEO from Day One I treated SEO as an afterthought. Should've optimized for "GitHub README generator" from the start. ### 4. Document the Journey I built Gitskinz but didn't blog about it until now. The building process would've been great content. ## The Funny Part Gitskinz became my portfolio piece. Recruiters see it and immediately understand: - I can identify problems - I can build solutions - I can ship products - I can grow user bases **One side project did more for my career than months of LeetCode.** ## Open Source Impact Gitskinz taught me: - The joy of building for users, not profit - The power of community feedback - The satisfaction of helping others It proved that **you don't need VC funding or a startup to make an impact.** ## Why "Brutalist"? The brutalist design wasn't accidental. It represents: - **Raw and honest**: Like the GitHub platform itself - **Function over form**: Code-first aesthetic - **Standing out**: Not another Material Design clone - **Developer culture**: We like things that look "hacker-y" ## The Best Way to Learn Gitskinz taught me more than courses ever could: - **React**: Built 60+ component variations - **State management**: Handled complex form inputs - **Deployment**: Learned Netlify inside out - **Marketing**: Grew users organically - **User research**: Listened and iterated **You don't learn by consuming tutorials. You learn by building products people use.** ## Future Plans I'm considering: - User-submitted templates - GitHub Actions integration - Profile analytics - Team profiles - API for developers But honestly? I'm happy with Gitskinz as is. It solves the problem it set out to solve. ## Your Turn If you're a developer without a side project: 1. **Find your itch**: What frustrates you daily? 2. **Build the simplest solution**: Don't overthink it 3. **Ship publicly**: Share your progress 4. **Gather feedback**: Listen to users 5. **Iterate quickly**: Weekly updates, not monthly You don't need a revolutionary idea. You need a problem you care about solving. ## The Real Lesson Gitskinz isn't special because of the tech stack or the templates. It's special because: **I built it to solve a problem, shared it with others, and helped thousands of developers in the process.** That's what side projects should do. --- **Check out Gitskinz:** [gitskinz.netlify.app](https://gitskinz.netlify.app) **From Mumbai with code.** If you use Gitskinz, tag me—I'd love to see what you create! ]]> Sun, 01 Sep 2024 00:00:00 GMT Nabil Salim Thange thangenabil@gmail.com (Nabil Salim Thange) Project Learning Open Source