AI has been moving at the speed of light. What's regular now was rocket science a mere 6 months ago. Some 20 months ago, I was on X which was popping off about this popular indie developer who had made an AI startup which acted like a mental health counsellor for people in need. It was a paid service and was being marketed as a cheaper alternative to mental health services.

The discourse was... heated, to say the least.

On one side, people rightfully pointed out that calling something "TherapistAI" when therapy is a licensed, regulated profession requiring years of specialized training was, at best, misleading. At worst? Potentially exploitative of vulnerable people who might genuinely need professional help but couldn't afford it.

On the other side, the tech optimists argued that the creator had put in time and effort, built something functional, and deserved to be compensated like any other product builder. Fair point, honestly.

Me? I sat somewhere in the middle, but leaning skeptical. The whole thing felt a bit grifty—marketing to people in need with promises a chatbot fundamentally couldn't deliver. But I'll admit, I was also curious. How hard could it actually be to build something like this?

Turns out: not hard at all.

And that's how www.GrifterAI.com was born over a single weekend. Yes, the name was intentional. Yes, I'm aware of the irony.

The 36-Hour Sprint

I started on a Saturday morning with a simple goal: build a functional AI life coach that people could actually use, and do it fast enough to prove this wasn't some revolutionary technical achievement worthy of the hype it was getting.

The clock was ticking. I gave myself the weekend.

Finding the Right Model

The first step was finding and deploying the right large language model. I turned to Google's Model Garden and Vertex AI—honestly one of the better decisions I made. Model Garden gave me access to a variety of pre-trained models, and after some experimentation, I settled on Llama 70B.

Here's some context: at the time, Llama 70B was the largest open-source model available. It was the bleeding edge. If you wanted something more powerful, you were looking at proprietary models with hefty API costs or academic research models that were a nightmare to deploy.

Fast forward to today? The landscape is unrecognizable. We've got Llama 3.1 405B, Mistral models at various sizes, Qwen, Phi, Gemma, Claude, GPT-4—an absolutely dizzying array of options at every scale and specialization. Back then, the choice was simpler because there simply weren't that many options. You picked Llama 70B and you were working with the best open-source had to offer.

It really drives home just how fast AI has been moving. What was cutting-edge 20 months ago is now just... normal. Entry-level, even.

Vertex AI made the deployment process surprisingly smooth. Within a few hours, I had the model spun up and accessible via an API. The real work, though, was in the fine-tuning.

Fine-Tuning for the Use Case

Out of the box, large language models are generalists. They're great at answering questions about medieval history or debugging Python, but for something like life coaching—where tone, empathy, and conversational flow matter—you need to fine-tune.

I spent a good chunk of Saturday afternoon curating a dataset from Kaggle and running fine-tuning jobs. The goal was to make the model sound less like a corporate FAQ bot and more like someone you'd actually want to talk to when you're having a rough day. Empathetic but not patronizing. Thoughtful but not preachy.

Securing the Inference API

When you're running a 70B model on cloud infrastructure, inference isn't cheap. The last thing I wanted was some random person stumbling onto my API endpoint and racking up thousands in GPU costs.

I used Google's built-in security protocols as a baseline, locking down incoming requests to just my IP. But I didn't stop there, I built additional custom security layers on top; Token-based authentication, rate limiting, request validation. If you somehow got the API endpoint, you still weren't getting through without the right credentials.

GPUs are expensive, and I wasn't about to fund someone else's experimentation.

Architecture: Why Telegram?

By Sunday morning, I had a working model and a secure API. Now I needed to make it accessible to users. This is where most people would start building a fancy web app with React, authentication flows, responsive design, the whole nine yards.

I went a different route: Telegram.

The Case for Telegram

Telegram has over 900 million active users. Many people already have it installed and already know how to use it. There's zero friction to getting started: click a link, send a message, done.

Compare that to building a standalone web app where users need to:

• Create an account

• Verify their email

• Remember yet another password

• Navigate a new interface

• Probably download a mobile app if they want it on their phone

Telegram eliminated all of that. It's unobtrusive, familiar, and just works. Plus, the Telegram Bot API is incredibly well-documented and easy to integrate.

So I built www.GrifterAI.com as an entry point—clean landing page, quick explanation—but it redirects straight to the Telegram bot. The website exists for discovery and SEO; the actual experience lives in Telegram.

The Technical Stack

For the backend, I used Node.js to handle the Telegram Bot API integration. Node's async nature made it perfect for managing multiple concurrent conversations and API calls to Vertex AI for inference.

For the database, I went with SQLite: Was it scalable at enterprise scales? Eh. Not like I cared, tbh - for a project at this scale, SQLite is fast. No network latency, no connection pooling headaches, no overhead from running a separate database server. It's a single file, it's blazingly quick for reads and writes, and it was exactly what I needed. I would love to be in a position where I would have to worry about database scaling. For now, this worked.

The flow was simple:

1. User sends a message via Telegram

2. Node backend receives the message via webhook

3. Backend sends the full context to Vertex AI inference API

4. Model generates a response

5. Backend sends response back to user via Telegram

Clean. Efficient. Worked like a charm.

The Marketing Advantage

Here's the underrated part: by using Telegram, I completely offloaded user acquisition and marketing. Telegram has built-in virality—users can share bots with a single tap, add them to groups, forward messages.

This meant I could focus on what I actually enjoy: the technical side. Model performance, API optimization, security hardening, conversation quality. Let Telegram handle the rest.

The Hardest Part (Spoiler: It Wasn't the Tech)

You know what took the longest? Coming up with a name.

I'm not joking. The technical implementation—deploying a 70B model, fine-tuning it, building a Telegram bot, securing an API—took about 36 hours of focused work. Naming it? That was at least 3 of those hours.

Finally, I landed on GrifterAI. It was cheeky, self-aware, and perfectly captured the spirit of the project: calling out the grift by becoming the grift. The domain was available. Done.

The Reality Check: Economics of AI

I launched GrifterAI with a simple plan: offer the first 5 messages free, then redirect people to my socials for more. The idea was to give people a taste, build an audience, figure out monetization later.

That lasted exactly one day.

Running a 70B model isn't like hosting a static website for $5/month. Every single inference call costs real money. Fine-tuning? Even more expensive. GPU time on Vertex AI adds up fast, and I quickly realized that "free tier + audience building" wasn't sustainable unless I wanted to hemorrhage money.

So I made GrifterAI paid-only. Still haven't figured out payment processing yet (Stripe integration is on my TODO list, lmao), but the principle stands: if you're running infrastructure this expensive, you need a revenue model that isn't "hope people like me enough to donate.". Eventually, with no want to market it or profit off of it, I shut the inference down cuz the deployment costs were piling up.

Why I'm Posting This Now (And Why I Didn't Before)

Here's the thing: I actually wrote a LinkedIn post about all of this when I first built GrifterAI. Got all fired up, drafted the whole thing, added screenshots, the works. It's still sitting in my LinkedIn drafts, unpublished.

Why didn't I post it? A couple of reasons.

First, dunking on someone, even someone whose business model I found questionable didn't feel like a positive use of my energy. Yeah, I built the thing to prove a point, but publicly calling someone out? That's just adding negativity to the internet, and we have enough of that already.

Second, and honestly more importantly, I didn't want to contribute to the AI noise. If you've been on LinkedIn in the past year, you know what I'm talking about. Everyone and their dog was posting about AI. "10 ways ChatGPT will revolutionize your workflow!" "AI is coming for your job!" "I used AI to write this post about AI!" Most of it was just recycled takes and copy-pasta content that added nothing to the conversation.

The signal-to-noise ratio around AI was already terrible, and I didn't want to make it worse. I decided I'd only post when I had something genuinely useful to share—actual learnings, technical insights, something that moved the conversation forward instead of just adding to the echo chamber.

Look, I'm not interested in playing the algorithm game or chasing engagement metrics. I share things because they matter to me—deep dives into software architecture, interesting problems in distributed systems, what it's actually like working as an engineer. This blog exists as much as a personal archive as it does for anyone else. Years from now, I want to be able to look back and remember how I solved this problem or what I was thinking about at this point in my career. If other people find it useful along the way, that's a bonus.

So why now? Because I do have something to share. Real technical implementation details. Honest reflections on what worked and what didn't. Lessons about infrastructure costs, architecture decisions, and the actual barriers (or lack thereof) to building AI products. And yeah, as social proof that I actually built the thing and learned from it.

This isn't a hot take or a thought leadership piece. It's just documentation of a weekend project and what came out of it. That felt worth sharing.

What I Learned

This whole project reinforced something I've long suspected: the technical barrier to entry for AI products is lower than ever. What once required a PhD and a research lab can now be done by a single developer over a weekend with the right tools.

That's both exciting and a little terrifying.

On the technical side, I learned a ton about:

• Large language model deployment and fine-tuning at scale

• Managing inference costs and API security

• Real-time conversational AI architecture

• The trade-offs between different deployment platforms

On the product side, I learned that sometimes the best UX decision is to not build a custom interface. Telegram's ubiquity and simplicity beat a bespoke web app for reach and accessibility.

On the ethical side? Look, I still think marketing an AI as a replacement for mental health services is sketchy. But I also gained a deeper appreciation for the infrastructure and thought that goes into building these things—even if I fundamentally disagree with how they're positioned.

The Point

So did I prove my point? Yeah, I think so.

Building an AI startup in 2025 isn't rocket science. The tools are accessible, the models are available, and the infrastructure exists. What separates a weekend project from a "real" startup isn't technical complexity—it's positioning, marketing, and ethics.

GrifterAI still exists at www.GrifterAI.com (well, it still has the link to Telegram too. Pop in and say Hi on the channel :P). It's functional, it works, and people have used it. I'm proud of the technical achievement, even if the whole thing started as a slightly petty "I could do that" moment.

Because honestly? Sometimes spite is the best motivator.

And if you ever find yourself thinking "that doesn't seem that hard"—try building it. You might surprise yourself.

TL;DR: Saw an overhyped AI startup on Twitter, built my own version in 36 hours using Google Vertex AI, Llama 70B , Telegram, and Node.js. Learned a lot about LLM deployment, API security, and the economics of running AI at scale. Named it GrifterAI because irony is delicious and I like to think I cooked.

Why Absolute Imports Matter

The difference is immediately clear.

Before (Relative Imports):

TypeScript

import Button from '../../../components/ui/Button'
import { useAuth } from '../../../../hooks/useAuth'
import logo from '../../assets/images/logo.svg'

After (Absolute Imports):

TypeScript

import Button from '@/components/ui/Button'
import { useAuth } from '@/hooks/useAuth'
import logo from '@/assets/images/logo.svg'

Benefits

• No more path confusion when moving files.

• Cleaner, more readable import statements.

• Easier refactoring and file organization.

• Consistent imports across your entire project.

The Complete Setup

To get absolute imports working, you need to tell both TypeScript (for type checking and autocompletion) and Vite (your bundler) how to resolve these new paths.

1. tsconfig.json

This is the root TypeScript config. We just need to ensure it references our other TypeScript configurations. The key settings for path aliases will go in tsconfig.app.json.

JSON

{
  "files": [],
  "references": [
    { "path": "./tsconfig.app.json" },
    { "path": "./tsconfig.node.json" }
  ]
}

2. tsconfig.app.json

This file configures TypeScript for your application code. Here we define the baseUrl and paths so that TypeScript understands the @ alias.

JSON

{
  "compilerOptions": {
    "composite": true,
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo",
    "target": "ES2022",
    "useDefineForClassFields": true,
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Path Alias Configuration */
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    },

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  },
  "include": ["src"]
}

3. vite.config.ts

Finally, update your Vite configuration to resolve the path aliases during the build and development process.

TypeScript

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    }
  }
})

Quick Setup Steps

1. Install @types/node (required for using path and __dirname in vite.config.ts):

   Bash

    npm install -D @types/node
   

2. Copy the configurations above into your respective files (tsconfig.json, tsconfig.app.json, and vite.config.ts).

3. Restart your development server:

   Bash

    npm run dev
   

4. Restart the TypeScript server in your IDE (In VS Code: Cmd + Shift + P → "TypeScript: Restart TS Server").

Usage Examples

Now you can use clean, absolute paths everywhere in your project.

TypeScript

// Components
import Header from '@/components/Header'
import Button from '@/components/ui/Button'

// Assets
import logo from '@/assets/logo.svg'
import heroImage from '@/assets/images/hero.jpg'

// Utils & Hooks
import { formatDate } from '@/utils/date'
import { useAuth } from '@/hooks/useAuth'

Key Configuration Details

• "baseUrl": ".": This tells the TypeScript compiler that the root for path resolution is the project's root directory (where tsconfig.json is located).

• "@/*": ["src/*"]: This is the path mapping. It tells TypeScript that any import starting with @/ should be mapped to the src/ directory.

• path.resolve(__dirname, './src'): This is used in vite.config.ts to create a reliable, absolute file path to your src directory, ensuring Vite can find the files correctly regardless of the operating system.

Your imports are now cleaner, your code is more maintainable, and file reorganization is effortless. No more counting ../ levels!

1. NoHello : <-- Click the link. Essentially, it says, when you message someone, do NOT just say hello and wait for the other person to respond. Instead, start with the message you wanna communicate already. I have made improvements on this formula. The way I send messages is

   "Hi <recipient>, This is <significance of message ie, urgent or important, or both>, I need <expected time in minutes to explain the task> minutes of your time. It is because <briefly explain the issue>. Can we get on a call?"

2. Over Communicate: No harm has ever come from telling your colleagues more than they need to know. A LOT of harm has come from not telling your colleagues what you assume they know already. All of this in an appropriate and relevant context of course. You're facing a problem and you're already solving it, drop a message to your reporting manager anyway. Your dog is getting his vaccine shots, probably refrain from telling your manager.

3. Pictures help: We are all children at heart 🤣. When describing a problem, attach relevant screenshots/pictures for better understanding. They will always fetch quicker results and less confusion.

4. Listicles: Nobody has the time to read a paragraph. Break relevant things down in a bullet/numbered list. This blog is an example.

Over the many years that I have worked remotely, I've literally set the culture for high performing teams that have worked on products like Dream11 and Hotstar and this is the method of communication that has worked for me - I hope it works for you too.

Today, I acted like a total dumbfuck!

I just struggled 10 minutes to setup a locally saved image as a background in a NextJS component using tailwind.

I am writing this so that if you're in the same position, you don't get frustrated as I did.

      #Component where you want to add the image
      #Save the image in the nextjs public folder.

      <div
        className={`h-screen bg-no-repeat bg-cover`}
        style={{ backgroundImage: `url('/awesome-bg.png')` }}
      >
            Text inside the component
      </div>

Remember to refer back to this if you forget again, you dumbfuck!

Why would you wanna do this?

• You wanna get rid of MongoDB Atlas

• You want a FREE solution

• You want autonomy over how to manage and deploy your server

Pre-requisites:

• Basic understanding of how to run a docker image

• Basic understanding of what MongoDB is.

For when you just need to spin up a quick MongoDB server don't want to spin up a MongoDB Atlas instance (Ugh, sign up, login, spin up a server and wait for it to get ready. It's a hassle)

Docker allows to quickly spin up a server ad-hoc without needing to sign up on any service and pay for any service. All you need is to have docker installed on your machine and internet connection (to download the mongodb image from the doker registry).

How to run docker inside a container

Once you have both, here's how you set it up. Firstly, open up the terminal and type the following command

docker run --name mongodbcontainer -p 27017:27017 -e MONGO_INITDB_ROOT_USERNAME=mongodbrootusername -e MONGO_INITDB_ROOT_PASSWORD=mongodbrootpassword -d mongo

In the above command,
1. "-p" denotes port. Left side denotes the port on YOUR COMPUTER and right side denotes port to listen to INSIDE DOCKER CONTAINER

2. "-e" denotes environment variables

3. "-d" denotes daemon mode, ie the process will run in the background and not take up your terminal

4. "--name" denotes the name that you can assign to the container

Connect MongoDB inside container to your app

Once you've run this command, it will spin up a mongodb server inside a docker container. To connect to that container from a (for example, nodejs) app, here's the connection string you must enter.

mongodb://mongodbrootusername:mongodbrootpassword@localhost:27017/?retryWrites=true&w=majority

And that's that. You are now conneted to an instance of MongoDB running inside a container on your machine.

Docker remains the quickest way of setting up a Postgres database server. Here's how to do so.

Sometimes, we just need to set up a postgres database server, and if you have docker - spinning up a container is always the quickest and cleanest way of setting up a Postgres server

For example, when you need to quickly setup a Express Rest API server using PostGres with Prisma, like I need to do today. Here's how you do it.

docker run --rm --name postgres-db -p 5433:5432 -e POSTGRES_PASSWORD=mysecretpassword -d postgres:13-alpine

Please Note: we're mapping port 5432 of the container to port 5433 of your local machine/system/computer on which you are writing code. This is intentional and serves to drive understanding of how ports works. The explanation is below:

• postgres-db is the name of the container you spin up.
• 5432 is the default port at which postgres runs. You can, if you so wish, map your system's port to container's port. In this case, 5433 is the port at which you will find the server on your local machine.
• mysecretpassword is the password to log in to the db server
• postgres is the default user AND default Database. It is not mentioned in the docker command posted above.
• postgres:13-alpine is the image we're pulling.

Assuming everything runs without an error, you can connect to the server using the connection string in the following format: postgresql://default_user:password@localhost:5432/default_db?schema=public

Therefore, your string becomes

postgresql://postgres:mysecretpassword@localhost:5433/postgres?schema=quotes

And that's it.

If you'd like to know how to connect to this (or any) postgres server using Shell/Terminal, you can find it in an upcoming blog.

You can still run the docker container by explicitly stating the platform, such that your run command becomes

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=admin --platform=linux/x86_64 -d mysql

And now your container should form and run smoothly.

Caveats --> This is not an ideal approach. This is essentially using an emulation of the host machine to run the container and that causes its own issues like poor performance. If you'd like me to discuss problems with this approach and ideal solutions, let me know and I'll write another blog about it.

TL:DR

1. Make sure your Node version is above v13 (if it is not, update your version of node)
2. In the package.json file, paste the following before dependencies

  "type": "module"

Such that your package.json loos something like below

Et Voila.

Still here? Looking for explanation. Read on.

Compatibility

Since Node v13 and above, NodeJS has an experimental support for ES Modules by default as declared here, ie, Node will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements within ES module code :-

--> Files ending in .mjs.

--> Files ending in .js when the nearest parent package.json file contains a top-level field "type" with a value of "module".

--> Strings passed in as an argument to --eval or --print, or piped to node via STDIN, with the flag --input-type=module.

Difference b/w CommonJS vs ES6 module syntax

Support

As of April 2021, an overwhelming majority of browsers support ES6 modules so you don't have to worry about the support

If you found this helpful, consider subscribing to my social channels? Cheers!

Hi, I am Sarthak. Some of you know me, most of you don't, which is what I intend to change with what I am starting today.

Well, let me give you a quick heads up about myself - I'm a Full Stack (meaning I work on FrontEnd and Backend both) Web/Mobile/DevOps engineer and a hobbyist game developer. I have been doing this for over six years now, in which I have done a bunch of important projects, some of which you'll find on my website - which, to be fair, is still a work in progress, so all of y'all are invited to send feedback and suggestion.

So, why am I writing this blog? To let y'all know and to hold myself accountable by committing socially to improving myself as a developer and showcase my work! I intend to do that by means of LiveStreaming coding, so that you can code along while having a peek into my way of implementing solutions and taking your questions, solving problems basically. I'm also committing to documenting my journey, despite how much my engineer instinct tell me to avoid documentations!

With that being said, I'll leave y'all with links to my various channels and ask y'all to see me there, to feed me encouragement and suggestions and I'll put my best efforts to make it worth your time.

Keep an eye out for these:

NewsLetter - Where I write my engineering observations, tip and tricks. I take interviews with people in tech and give you updates about job openings and resources. If you want all this goodness, subscribe to it here

Twitch Channel - Where I take coding challenges, take up and build projects, solve problems and interview questions - all on livestream. Subscribe if you are interested in seeing the process, in its entirety, of solving engineering problems. I also build projects in real time so you can see the problems I encounter and how I arrive at their solutions. You also get to be a part of a helpful and close knit community of developers(over discord). Subscribe and become a follower here

YouTube Channel - A place where I put abridged versions of interview question solutions, tutorials, and general tech content. Follow if you want tech tutorials, abridged versions of what we do on the live stream and become a part of a close knit community of developers - subscribe to it here

Say you're more of a fun-loving who breathes social media, y'know what, so do I. Don't believe me? Check out my Instagram and Twitter to see for yourself.

And that's it from my side for now. I'll see you on the other side of this blog.