DEV Community: Dharanidharan

Next.js vs Laravel for a SaaS MVP: Which Should a Startup Pick?

Dharanidharan — Tue, 13 Oct 2026 14:30:00 +0000

You have a SaaS idea. You talk to two developers. One says, 'Use Next.js.' The other says, 'Laravel will be faster.' Both sound sure.

The good news is that both can be right. For most SaaS products, either one will work. The better question is which one fits your product, your budget and the person who will build it.

In this guide we compare Next.js vs Laravel for SaaS in plain English. You will get a side-by-side table, clear rules for when each one wins, and a 5-question checklist you can use today. We build with both, so we have no reason to push you to one.

The short answer

Pick Laravel if your product is mostly logins, dashboards, user roles, subscriptions, emails and background jobs. Many of these come built in, so you spend less time connecting pieces.
Pick Next.js if your product has a rich, interactive screen (think editors, boards or live data), or if your team already works in JavaScript.
Either way, a focused MVP can ship in 4 to 8 weeks. The difference is where the time goes, not whether you can launch.

Still not sure? Scroll down to the 5-question checklist near the end.

What are Next.js and Laravel, in plain English?

Next.js is a framework built on React, a popular tool for making app screens. You write both the front end (what users see) and the back end (the logic behind it) in JavaScript or TypeScript. It is very flexible. You choose your own tools for the database, login and payments.

Laravel is a framework for PHP. It is known as 'batteries included'. Login, email, background jobs (called queues), scheduled tasks and database tools are part of the toolkit. For subscriptions, a Laravel package called Cashier works with Stripe and Paddle.

A simple way to think about it: Laravel is like a furnished flat. You move in, then change what you like. Next.js is like an empty flat with a great layout. You have total freedom, but you choose and buy each piece of furniture yourself.

Neither is better in general. It depends on what you are building.

Next.js vs Laravel for SaaS: side by side

What matters	Laravel	Next.js	Edge
Build speed for a typical SaaS (logins, billing, admin)	Usually faster, because many parts are built in	More setup, because you pick and connect each part	Laravel
Built-in features (login, email, queues, scheduler)	Included	Mostly add-ons	Laravel
Rich, interactive screens	Possible with Livewire or Inertia	Very strong with React	Next.js
One language everywhere	PHP on the back end, JavaScript if you add React	JavaScript or TypeScript everywhere	Next.js
Background jobs	Built in	Needs an extra service for long jobs	Laravel
Hosting	A normal server, or managed tools made for Laravel	Vercel and other platforms	Depends
Hiring	Large developer community	Large developer community	Tie
SEO for public pages	Pages render on the server	Pages render on the server	Tie
Mobile app later	A Laravel API works with any mobile app	Same language as React Native	Depends

Notice how often the answer is 'depends'. That is honest. The right pick comes from your product, not from a trend.

When Laravel is the better pick

Laravel tends to win when the heavy work happens behind the screen.

Lots of rules and roles. Admin panels, permissions, invoices and reports are everyday Laravel work.
Subscriptions and billing. Cashier handles plans, trials and invoices with Stripe or Paddle, so you do not build these from scratch.
Work that runs in the background. Sending emails, importing files and calling AI services are easier when queues are built in.
Live updates. Laravel Reverb adds WebSockets, which is useful for streaming results or live notifications.
A small team or a solo developer. Fewer decisions mean fewer moving parts and a faster first version.

Our Vektr platform is a good example of this kind of product: a multi-tenant AI chatbot with search over your own documents, live streaming answers and metered Stripe billing. This is where Laravel's queues, WebSockets and billing tools fit well.

If this sounds like your product, read more about our custom web app development.

When Next.js is the better pick

Next.js tends to win when the screen itself is the product.

A very interactive interface. Drag and drop, live collaboration, rich charts and editors are a natural fit for React.
A JavaScript team. One language across front end and back end means less switching and easier sharing of code and types.
A React Native app on the roadmap. You can share the language and some logic between web and mobile.
Public pages and the app together. Your marketing pages, blog and app can live in one project. This website runs on Next.js, with its pages, blog and free tools in one codebase.

The trade-off is setup time. With Next.js you choose and connect the login system, the database tool, the payments library and the background jobs yourself. Each choice is fine on its own. Together they add up, and a rushed choice can cost you later.

Can you use both together?

Yes. Some teams use Laravel as the API and Next.js as the front end. This makes sense when a web app and a mobile app share one API, or when separate people own the front end and back end.

The cost is real, though. You get two codebases, two deployments, and more to secure and monitor. For a first MVP, one stack is usually enough. Start simple, and split later if you truly need to.

Cost, hiring and maintenance

No stack is cheaper by default. The cost of a SaaS MVP comes mainly from how many features you build, how custom the design is, which tools you connect, and who builds it.

Laravel can lower build time on backend-heavy products, because the basics are already there.
Next.js can cost less when the work is mostly interface design and the team only knows JavaScript.
Hosting is rarely a big cost at MVP stage for either one.
Hiring: both have large communities. The more useful question is whether you can find and keep a developer who knows the stack well. A strong developer in either stack beats an average one in the 'perfect' stack.
Maintenance: both frameworks release updates often. Plan time to keep packages current and secure.

Want a rough budget before you talk to anyone? Try our free web app cost estimator, or read our guide to custom web app cost.

Does SEO matter for your SaaS?

For most SaaS products, the public pages need SEO: your home page, pricing, features and blog. The logged-in app does not, because search engines do not see it.

Both Next.js and Laravel can render pages on the server, so search engines can read your content. That means SEO should rarely decide your choice. Page speed, clean URLs and good content matter much more, and you can get these right in either stack.

If you are not sure whether you need a website or an app at all, read Website vs Web App: How to Choose.

How to choose in 5 questions

Answer these honestly and count which side wins.

What is most of the work? Dashboards, billing, roles, emails and jobs point to Laravel. A rich, interactive interface points to Next.js.
What does your developer know best? Pick that one. Speed and quality come from experience.
Will you build a mobile app soon? If you plan React Native, Next.js shares the language. If not, either stack works with an API.
How fast must you launch? For a backend-heavy product on a tight timeline, Laravel often saves setup time. For an interface-heavy one, Next.js often does.
Who will maintain it in a year? Choose a stack you can hire for, or one your developer will support.

If most answers point one way, you have your choice. If they are split, go with the stack your developer can ship fastest.

Our honest take

We build web apps in both Next.js and Laravel, so we do not have a favourite to sell you. Our rule is simple: start from your product, not from a trend.

For an MVP, speed to your first real users matters most. A good-enough stack that ships beats a perfect stack that never launches. You can always improve it once people are using it.

Not sure which stack fits your idea?

Tell us what you are building, and we will recommend a stack in plain English. No pressure and no jargon. Book a free 30-minute call, or learn how we build an MVP in 4 to 8 weeks.

How to Build RAG Chatbots for Clients as a Freelancer

Dharanidharan — Wed, 07 Oct 2026 13:31:36 +0000

Building a RAG chatbot is the easy part. Getting a client, agreeing on what you will build, keeping their documents safe, and getting paid on time: that is where freelancers get stuck.

This post is a simple, step-by-step guide to doing client work with RAG chatbots, from the first call to the monthly check-in. It is part 4 of my RAG series:

Part 1: How to Build a "Chat With Your PDFs" App
Part 2: Why Your RAG Chatbot Gives Wrong Answers
Part 3: How Much Does a RAG Chatbot Cost to Run?

You do not need to read them first, but I will point to them when they help.

Who Needs a RAG Chatbot (and What to Promise)

The best clients are small businesses that answer the same questions again and again. For example:

Coaches and trainers (course details, schedules, rules)
Real estate agents (listing details, documents, process)
Clinics and training centers (timings, services, forms)
Online shops (return policy, shipping, product details)
Software teams (help center and documentation)

They all have two things in common: they already have documents with the answers, and someone on their team is tired of typing the same replies.

What you can promise:

The chatbot answers questions using only the client's documents.
It works day and night.
It shows where the answer came from, so people can check it.
When it does not know, it says so and shows how to contact the business.

What you should never promise:

That it knows everything
That it is always right
That it replaces the client's staff

Promising less and delivering what you promised is how you get repeat work.

A tip on finding clients: start with one type of business. When you know one type well, your demo, your questions, and your pitch all get better. Show them a demo on their own document (see step 3 below). People believe what they can see working.

The Client Process, Step by Step

Step 1: The first call

The goal of this call is to understand the problem, not to sell. Ask the questions in the next section. At the end, say what you need next: a few real documents and a list of the questions customers ask most.

Step 2: Collect the documents

Ask for the original files, not photos or screenshots. Word, PDF with real text, or plain text files are best. Ask three things:

Are these documents up to date?
Is anything in them private or secret?
Who in the business can answer my questions about them?

Open every file yourself. As we saw in part 2, messy or scanned PDFs are one of the main reasons for wrong answers.

Step 3: Make a small free demo

Take one short document from the client, 1 or 2 pages, and build a working chatbot on it. Show it to them with 5 real questions.

Keep the free part small. A demo on one document shows them it works. Building the whole project for free does not. Do not start the real build until the scope is agreed and the first payment is made.

Step 4: Agree the scope in writing

This is the most important step, and most beginners skip it. Write one page that says what you will build and what you will not. There is a template in the next sections.

Step 5: Build

Use the same steps from parts 1 and 2: extract the text, clean it, split it into chunks, embed it, store it, and answer from it. Keep each client's data separate (code below).

Step 6: Test with 20 real questions

Ask the client for 20 questions that their customers really ask. You can find them in their WhatsApp chats, emails, or social media messages. Run all 20 through the chatbot and mark each answer as:

Right
Partly right
Wrong

Fix the problems, then run all 20 again. Do not launch until every answer is right, or the bot safely says "I could not find this". Show the client the results. It builds trust and it sets honest expectations.

Keep these 20 questions. You will use them again every month.

Step 7: Launch and hand over

Give the client the link, QR code, or website widget. Then spend 30 minutes with them:

Show how people use it.
Show how to send new or changed documents.
Explain what it can and cannot do.

Give them a one-page guide they can keep.

Step 8: Support period

Say in the scope how long you will fix problems for free after launch (for example 2 weeks). After that, monthly support starts.

Questions to Ask Before You Start

What questions do your customers ask most? Can you give me 20 real examples?
Who will use the chatbot: customers, your staff, or both?
Which documents should it use? How many pages? In which languages?
Where should it live: a link, a QR code, your website, or WhatsApp?
How often do the documents change? Who will send me the new versions?
What should the chatbot never talk about? (For example prices, medical advice, or legal advice)
What should it say when it does not know the answer?
Is any document private or secret?
Who will pay for the AI usage: you or me? (More on this below.)

The One-Page Scope

Here is a simple template. Copy it, change it for each client, and send it before you start. (I am not a lawyer. For bigger projects, ask a lawyer to look at your template once.)

PROJECT: AI chatbot for [Client name]

WHAT IT DOES
- Answers questions using only the documents you give me.
- Shows which document the answer came from.
- Says "I could not find this" and shows your contact details
  when the answer is not in the documents.

WHAT IT DOES NOT DO
- It does not give legal, medical, or financial advice.
- It does not use information outside your documents.
- It does not take bookings, payments, or other actions
  (these can be added later as a paid extra).

DOCUMENTS
- Up to [number] documents / [number] pages, in [language].
- The timeline starts when I receive all the documents.

LIMITS
- Up to [number] questions per month.
- Above that, extra questions cost [amount] per [number].

AI COSTS
- Paid by: [client / me]. Billing account: [client's / mine].

OWNERSHIP
- You own your documents and your chatbot's content.
- I own the code. You get the right to use it for your business.
  (Change this line if you agree something different.)

UPDATES
- [Number] document updates per month are included.
- More updates: [amount] each.

SUPPORT
- Free fixes for [2 weeks] after launch.
- After that: monthly support at [amount] per month.

PAYMENT
- Setup fee: [amount]. [50%] before I start, the rest at launch.
- Monthly fee: [amount], paid on [date].

The most important lines are "What it does not do", the question limit, and "Paid by". These three stop most arguments before they start.

Keep Client Documents Safe

Clients trust you with their documents, and some are private. Follow these rules every time:

Never use free AI tiers for client data. As I explained in part 3, a free tier can use your content to improve the provider's products. Use paid accounts.
Tell the client which AI company processes their text. No surprises.
Keep every client's data separate. A question from client A must never see client B's documents. See the code below.
Answer only from the documents. Use the strict prompt from part 2.
Add a short note for risky topics. If the client is a clinic, a lawyer, or gives money advice, add a line like "This is general information from our documents, not professional advice."
Keep API keys out of your code. Use environment variables.
Sign an NDA if the client asks. And only collect the documents you need.
Delete on request. When a client leaves or asks, delete their documents, their vectors, and their saved questions. Tell them when it is done.
Back up your data. And test that you can restore it.

Privacy rules are different in every country. If your client works with personal data, ask them which rules apply.

One App, Many Clients

You do not need a new app for every client. One app can serve many clients, if each client has their own config and their own data folder. Here is a simple example (the names are made up):

import json
import faiss

CLIENTS = {
    'client-a': {
        'name': 'Client A',
        'index_path': 'data/client-a/index.faiss',
        'chunks_path': 'data/client-a/chunks.json',
        'tone': 'friendly and short',
        'monthly_limit': 1000,
        'fallback': 'Please contact us at hello@client-a.example',
    },
    'client-b': {
        'name': 'Client B',
        'index_path': 'data/client-b/index.faiss',
        'chunks_path': 'data/client-b/chunks.json',
        'tone': 'formal',
        'monthly_limit': 500,
        'fallback': 'Please call our office.',
    },
}

def load_client(client_id):
    config = CLIENTS[client_id]
    index = faiss.read_index(config['index_path'])
    with open(config['chunks_path']) as f:
        chunks = json.load(f)
    return config, index, chunks

def build_prompt(config, context, question):
    name = config['name']
    tone = config['tone']
    fallback = config['fallback']
    return f'''You are the assistant for {name}.
Answer using ONLY the context below. Use a {tone} tone.
If the answer is not in the context, say: 'I could not find this. {fallback}'

Context:
{context}

Question: {question}
Answer:'''

def within_limit(client_id, questions_this_month):
    return questions_this_month < CLIENTS[client_id]['monthly_limit']

The important idea: every question comes in with a client_id, and the app loads only that client's index. It never searches across clients. If you use a hosted vector database, the same idea works with one namespace or one index per client.

Pricing in 5 Steps

Work out the running cost. Hosting + database + AI at the client's expected number of questions. In part 3, a small business with about 1,000 questions a month came to roughly $8 to $15 a month, using prices I checked on October 6, 2026. Check current prices before you quote.
Count your time. Time to collect and clean documents, build, test, train the client, and support them later.
Set a setup fee. This pays for the first build. Ask for part of it (for example half) before you start.
Set a monthly fee with a question limit. It must cover the running cost, your update and support time, and some room for busy months.
Set a price for extras. Extra questions above the limit, extra document updates, new features.

Do not charge only your costs. The running cost for a small client is small. Your fee pays for your work, your reliability, and your time to keep the chatbot good.

The question of who pays the AI bill matters too. One simple way is for the client to create their own AI account and give you the key. Then their usage is their own cost, and you carry no risk. The other way is to pay the bill yourself and include it in your monthly fee, with a question limit to protect you.

Common Problems and What to Do

Problem	What to do
Documents are messy or scanned	Ask for the original files. If you can't get them, use OCR, check the text yourself, and charge for the cleanup. (See part 2.)
The bot gives a wrong answer	First print the retrieved chunks. Often the answer is missing from the documents, or the text extraction is bad. Fix the cause, then re-run the 20 test questions. (See part 2.)
The client asks for more features ("Can it also book appointments?")	Open the scope page. If it is not in there, it is a paid extra. Say it kindly and give a price.
The client expects it to know everything	Show the 20-question test results. Explain that the bot only knows the documents. Make sure the "I could not find this" answer shows how to contact them.
Old answers after documents change	Ask the client to send every new version. Embed only the files that changed. (See the hash tip in part 3.)
The client is slow to send documents	The timeline starts when you get all the documents. Write this in the scope.
Someone spams the public chatbot	Add a daily limit for each visitor and a monthly budget alert. (See part 3.)
The client is late to pay	Take part of the setup fee before you start, and pause support if the monthly fee is not paid. Write this in the scope.

A Simple Monthly Routine

The monthly fee is only fair if you do real work. Here is a routine you can follow for every client:

Check usage. How many questions did people ask? Are they near the limit? What was the AI bill?
Read the questions. Look at the ones where the bot said "I could not find this". They show what information is missing from the documents.
Re-run your 20 test questions. Make sure nothing broke.
Update the documents if the client sent new files.
Check hosting and backups.
Send the client a short note. Number of questions, the top questions, and the topics that are missing. This note shows the client what they are paying for, and it often leads to more work.

Your Checklist

Before you start

[ ] I asked the discovery questions.
[ ] I have the original documents, and I opened every one.
[ ] I have 20 real customer questions.
[ ] The one-page scope is signed or accepted in writing.
[ ] The first payment is received.

Before launch

[ ] Each client has their own data and config.
[ ] The prompt answers only from the documents and has an "I could not find this" line.
[ ] Sources are shown with every answer.
[ ] All 20 test questions are right, or safely say "I could not find this".
[ ] A public bot has limits and budget alerts.
[ ] API keys are in environment variables, not in code.

After launch

[ ] I gave the client a 30-minute training and a one-page guide.
[ ] The support period is in writing.
[ ] I have a monthly routine in my calendar.

Wrap-Up

Good RAG client work is not only about code. It is about promising the right things, agreeing the scope in writing, testing with real questions, keeping data safe, and checking in every month. Do those well, and one small client can become a steady monthly income.

If you would like a working codebase to start from instead of building everything yourself, I made a RAG chatbot source-code kit: Source code: .

Are you building RAG chatbots for clients, or planning to? Tell me in the comments what is your biggest worry, and I will try to cover it in the next part.

[Boost]

Dharanidharan — Tue, 06 Oct 2026 14:51:15 +0000

Dharanidharan

Oct 6

How Much Does a RAG Chatbot Cost to Run?

#webdev #python #tutorial #ai

7 min read

How Much Does a RAG Chatbot Cost to Run?

Dharanidharan — Tue, 06 Oct 2026 14:20:53 +0000

You built a "chat with your documents" app. It works on your laptop. Then someone asks: "What will this cost me every month?"

Here is the short answer, using real prices I checked on October 6, 2026:

A small test (1 PDF, 100 questions): under $1
A small business (1,000 questions a month): about $8 to $15 a month
A busy chatbot (10,000 questions a month): about $60 to $130 a month

With a small, cheap AI model, the answers are often the smaller part of the bill. Hosting and the database can cost more. In this post I will show where every dollar goes, how I did the math, and how to bring the bill down.

This is part 3 of my RAG series. Part 1 was How to Build a "Chat With Your PDFs" App. Part 2 was Why Your RAG Chatbot Gives Wrong Answers.

A note on prices: every price below comes from the official pricing page of each company, checked on October 6, 2026. Prices change often, so check the links at the end before you quote a client.

The 4 Parts of the Bill

Embeddings: turning your text into numbers so it can be searched. You pay once when you upload a document, plus a tiny amount for each question.
Vector database: the place where those numbers are stored.
The AI model (LLM): it writes each answer. You pay for every question, so this part grows as your users grow.
Hosting: the server that runs your app.

First, What Is a Token?

AI companies charge by the token. One token is about 4 letters, or about 0.75 of a word in English. Prices are given "per 1 million tokens".

You pay for two things: input tokens (what you send to the model) and output tokens (what the model writes back). Output costs more than input.

Current Prices (Checked October 6, 2026)

Embeddings

Option	Price
OpenAI text-embedding-3-small	$0.02 per 1M tokens
OpenAI text-embedding-3-large	$0.13 per 1M tokens
A local model (sentence-transformers, like in part 1)	Free, but it runs on your own server and needs RAM

Vector database

Option	Price
Pinecone Starter	Free. Up to 2 GB storage and 1M read units a month
Pinecone Builder	$20 a month
Supabase Free (Postgres with pgvector)	$0. 500 MB database. Free projects pause after 1 week of no activity
Supabase Pro	From $25 a month. 8 GB disk. Does not pause

AI model (price per 1M tokens)

Model	Input	Output
Gemini 3.1 Flash-Lite	$0.25	$1.50
Claude Haiku 4.5	$1	$5
Claude Sonnet 5.5	$2	$10

OpenAI and other companies also have cheap models. Check their pricing pages and use the same math below.

One warning about free tiers: Google's pricing page says that on the Gemini free tier, your content is used to improve their products. On the paid tier it is not. Do not send client documents through a free tier.

Hosting (Render)

Option	Price
Free web service	$0. 512 MB RAM. Has usage limits
Small paid service	$7 a month. Less than 1 CPU, 512 MB RAM
Medium paid service	$25 a month. 1 CPU, 2 GB RAM

Render's Hobby workspace is $0 a month plus the compute you use. Its Pro workspace is $25 a month plus compute.

How Much Does One Question Cost?

Let us use simple numbers:

Each chunk is about 400 words, which is about 530 tokens.
You send top_k = 4 chunks, so about 2,100 tokens.
Your instructions and the question add about 170 tokens.
So the input is about 2,300 tokens, and the answer is about 300 tokens.

The math for Claude Haiku 4.5:

Input: 2,300 / 1,000,000 x $1 = $0.0023
Output: 300 / 1,000,000 x $5 = $0.0015
Total: $0.0038 per question. That is less than half a cent.

The same math for all three models:

Model	Cost per question
Gemini 3.1 Flash-Lite	about $0.0010
Claude Haiku 4.5	about $0.0038
Claude Sonnet 5.5	about $0.0076

Note: models count tokens in different ways. Anthropic says its newer models, which include Sonnet 5.5, count about 30% more tokens for the same text. So Sonnet may cost a little more than the table shows. Treat all of these as good estimates, not exact bills.

What about embeddings? A 50-page PDF is about 25,000 words, or about 33,000 tokens. With text-embedding-3-small, that costs 33,000 / 1,000,000 x $0.02 = $0.00066. That is less than one-tenth of a cent. Embedding is almost never the problem.

Three Real Examples

	Small test	Small business	Busy chatbot
Questions per month	100	1,000	10,000
Documents	1 PDF	20 PDFs	20 PDFs
Setup	Your laptop and free tiers	Pinecone Starter (free) + Render $7	Supabase Pro $25 + Render $25
Fixed cost per month	$0	$7	$50
AI cost, Gemini Flash-Lite	$0.10	$1.03	$10.25
AI cost, Haiku 4.5	$0.38	$3.80	$38.00
AI cost, Sonnet 5.5	$0.76	$7.60	$76.00
Total with Flash-Lite	$0.10	$8.03	$60.25
Total with Haiku 4.5	$0.38	$10.80	$88.00
Total with Sonnet 5.5	$0.76	$14.60	$126.00

A few things to know about this table:

Embedding 20 PDFs adds only about one cent in total.
The small business setup uses an embedding API, not a local model, because a 512 MB server is too small for a local model.
Pinecone's own examples show its free plan handling thousands of searches a day for a small knowledge base, so 1,000 questions a month is far below its limit.
The busy chatbot uses Supabase Pro because it never pauses and it keeps daily backups.
These numbers do not include your domain name, taxes, bank fees for paying in dollars, or your own time.

Free Stack or Paid Stack?

The free stack ($0 a month) uses a local embedding model, FAISS from part 1 (or a free database tier), your laptop or Render's free plan, and a free AI tier. It is great for learning and for demos.

It is not good for real clients, for three reasons: the Gemini free tier may use your content to improve Google's products, a free Supabase project pauses after a week without activity, and free hosting has limits.

The cheap paid stack (about $8 to $15 a month) is the small business column above. It is always on, it keeps client data private, and it is still very cheap. For most small clients, this is the right place to start.

7 Ways to Cut Your Bill

1. Send fewer chunks. Going from top_k = 4 to top_k = 2 drops the input from about 2,300 tokens to about 1,230 tokens. That is about 46% less input cost. Test it with your own questions, because too few chunks can make answers worse (see part 2).

2. Limit the length of answers. Output tokens cost more than input tokens. On Haiku 4.5 they cost 5 times more. Most APIs let you set a maximum answer length:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model='claude-haiku-4-5-20251001',
    max_tokens=300,  # stops very long answers
    messages=[{'role': 'user', 'content': prompt}],
)
print(response.content[0].text)

3. Use the cheapest model that answers well. Test 20 real questions on two or three models. In the example above, Haiku costs half as much as Sonnet, and Flash-Lite costs about 70% less than Haiku. If the cheap model answers your questions well, use it.

4. Use prompt caching for the fixed part of your prompt. Anthropic charges only 10% of the normal input price when it reads text from its cache. This only helps for text that stays the same on every call, like a long set of instructions. The retrieved chunks change with every question, so they will not be cached.

5. Save answers to repeated questions. A business FAQ bot gets the same questions again and again. Save the answer, and the second time you pay nothing:

answer_cache = {}

def ask_with_cache(question):
    key = question.strip().lower()
    if key in answer_cache:
        return answer_cache[key]
    answer = ask_question(question, chunks, index)
    answer_cache[key] = answer
    return answer

This cache is lost when your app restarts. For a real app, keep it in your database. Clear it when the documents change.

6. Do not embed the same file twice. Save a fingerprint (hash) of every file. When a client re-uploads the same file, skip the embedding step:

import hashlib

def file_hash(path):
    with open(path, 'rb') as f:
        return hashlib.sha256(f.read()).hexdigest()

# Save the hash when you embed a file.
# Next time, if the hash is the same, skip it.

7. Protect a public chatbot. If you put the chatbot on a public website, anyone can send it thousands of questions, and you pay for all of them. Add a daily question limit for each visitor, and set a monthly budget or spending alert in your AI account.

How to Price This for a Client

If you build RAG chatbots for clients, do not guess a price. Use this:

Add up the monthly cost: hosting + database + AI cost at the client's expected number of questions. Use the table above.
Add your time: updating documents, fixing problems, answering messages.
Add some room for busy months.
Charge a one-time setup fee plus a monthly fee, and put a limit on questions per month (for example 1,000). Charge extra above the limit.
Decide who pays the AI bill. One simple way is for the client to create their own AI account and give you the key. Then their usage is their own cost, and you carry no risk.

Do not charge only your costs. In the small business example, the costs are about $8 to $15 a month. That will not pay for your time.

Wrap-Up

A RAG chatbot is much cheaper to run than most people think. For a small business, expect around $8 to $15 a month. The cost grows with questions, so choose a cheap model, send fewer chunks, limit answers, and protect public bots.

If you would like a working codebase to start from, I made a RAG chatbot source-code kit: Source code: .

What does your RAG chatbot cost you today? Tell me in the comments, and I will try to cover your biggest question in the next part.

Where These Prices Come From

All checked on October 6, 2026:

Why Your RAG Chatbot Gives Wrong Answers (And How to Fix It)

Dharanidharan — Mon, 05 Oct 2026 13:45:29 +0000

You built a "chat with your documents" app. You upload a PDF, ask a simple question, and the answer is wrong, half right, or completely made up.

If this happened to you, do not blame the AI model yet. In most RAG apps, wrong answers come from a few simple mistakes in how the document is prepared and searched. They are easy to fix once you know where to look.

This is part 2 of my RAG series. In part 1 we built a simple "chat with your PDF" app. Here, we fix the problems that show up when you test it with real documents.

First, Find Where the Problem Is

A RAG app does two jobs:

Retrieval: find the right pieces of the document for the question.
Generation: use those pieces to write the answer.

Most wrong answers are retrieval problems. The model never saw the right text, so it could not answer well. Before you change anything, print the pieces your app found:

relevant_chunks = search(index, chunks, query_embedding, top_k=3)

for chunk in relevant_chunks:
    print(chunk[:200])
    print('---')

If the answer is not in those pieces, fix retrieval (problems 1 to 4 and 7 below). If the answer is there but the reply is still wrong, fix the prompt (problems 5 and 6).

Problem 1: Chunks Are Too Big or Too Small

If chunks are too big, one chunk holds many topics and the search gets confused. If they are too small, a chunk has no useful meaning on its own.

Fix: start with about 300 to 500 words per chunk. Then test two or three sizes with your own questions and keep the one that works best.

for size in [200, 400, 600]:
    chunks = chunk_text(text, chunk_size=size)
    print(size, 'words ->', len(chunks), 'chunks')
    # rebuild the index and test the same 5 questions

Problem 2: No Overlap Between Chunks

When you cut text at a fixed number of words, a sentence can be split in half. The first half sits in one chunk and the second half in another. Neither chunk gives the full answer.

Fix: let each chunk repeat the last 50 words or so of the one before it.

def chunk_text(text, chunk_size=400, overlap=50):
    words = text.split()
    chunks = []
    step = chunk_size - overlap
    for i in range(0, len(words), step):
        chunk = ' '.join(words[i:i + chunk_size])
        if chunk:
            chunks.append(chunk)
    return chunks

Problem 3: The Text From the PDF Is Messy

This one is very common, and people forget to check it. If the text you extract is bad, everything after it is bad too. Look out for:

Scanned PDFs. They are pictures, so the extractor returns empty text.
Headers and footers. Lines like "Company Name | Page 4" repeat on every page and fill your chunks with noise.
Tables. They often turn into broken lines of numbers.

Fix: always print the extracted text and read it. Then clean it.

import pdfplumber
from collections import Counter

def extract_pages(pdf_path):
    pages = []
    with pdfplumber.open(pdf_path) as pdf:
        for page in pdf.pages:
            pages.append(page.extract_text() or '')
    return pages

def remove_repeated_lines(pages, min_pages=3):
    counts = Counter()
    for page in pages:
        for line in set(page.split('\n')):
            counts[line.strip()] += 1
    repeated = {line for line, n in counts.items() if line and n >= min_pages}
    cleaned = []
    for page in pages:
        lines = [l for l in page.split('\n') if l.strip() not in repeated]
        cleaned.append('\n'.join(lines))
    return cleaned

pages = extract_pages('manual.pdf')
empty = [i + 1 for i, p in enumerate(pages) if len(p.strip()) < 20]
if empty:
    print('No text on these pages (maybe scanned):', empty)

For scanned pages, use an OCR tool such as pytesseract to turn the pictures into text first.

Problem 3 and a Half: Tables

If your documents are full of tables, plain text extraction will not be enough. Try page.extract_tables() in pdfplumber and turn each row into a short sentence, like "Plan: Basic, Price: 500". Search works much better on sentences than on broken columns.

Problem 4: Wrong Number of Chunks (top_k)

top_k is how many chunks you send to the model. If it is too low, you miss part of the answer. If it is too high, you fill the prompt with noise and the model gets distracted.

Fix: start with 3 to 5. If your questions need facts from different parts of the document, go up. If answers look unfocused, go down.

relevant_chunks = search(index, chunks, query_embedding, top_k=4)

Problem 5: The Prompt Lets the Model Guess

If your prompt only says "answer this question", the model will happily use what it learned in training and mix it with your document. That is how made-up answers happen.

Fix: tell it clearly to use only the context, and what to say when the answer is missing.

prompt = f'''Answer the question using ONLY the context below.
If the answer is not in the context, say: 'I could not find this in the document.'
Do not use any outside knowledge.

Context:
{context}

Question: {question}
Answer:'''

Problem 6: No "I Don't Know" Path

A vector search always returns something, even when nothing in the document is close to the question. Without a check, your app sends useless chunks to the model, and the model tries its best to answer anyway.

Fix: add a distance cutoff. If no chunk is close enough, skip the model and say so.

def search_with_cutoff(index, chunks, query_embedding, top_k=4, max_distance=1.2):
    distances, indices = index.search(np.array([query_embedding]), top_k)
    results = []
    for dist, i in zip(distances[0], indices[0]):
        if i != -1 and dist <= max_distance:
            results.append(chunks[i])
    return results

relevant = search_with_cutoff(index, chunks, query_embedding)
if not relevant:
    print('I could not find this in the document.')

The right max_distance depends on your embedding model, so 1.2 is only a starting point. Print the distances for a few questions that the document answers and a few that it does not. Then pick a number between the two groups.

Problem 7: Wrong or Mixed Embedding Models

There are two mistakes here:

Using different models for the document chunks and the questions. The numbers will not match, and search will give random results. This often happens when you change the model but forget to rebuild the index.
Using an English-only model for other languages. If your documents are in Tamil, Hindi, or another language, an English model will search badly.

Fix: use one model for both, and rebuild the whole index if you change it. For other languages, try a multilingual model.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

doc_vectors = model.encode(chunks)           # for the document
query_vector = model.encode([question])[0]   # for the question, same model

Problem 8: No Sources, So No Way to Check

If your app only shows an answer, you cannot tell if it is right. And when it is wrong, you cannot tell why.

Fix: save the file name and page number with every chunk, and show them with the answer.

chunks_with_meta = [
    {'text': chunk_text_value, 'file': 'manual.pdf', 'page': 12},
    # one item per chunk
]

sources = [f"{c['file']}, page {c['page']}" for c in relevant]
print('Answer:', answer)
print('Sources:', ', '.join(sources))

Sources help your users trust the answer, and they help you debug it faster.

Your Debugging Checklist

When your RAG chatbot gives a wrong answer, go through this list in order:

[ ] Print the extracted text. Does it look right?
[ ] Print the retrieved chunks. Is the answer inside them?
[ ] Is the chunk size around 300 to 500 words, with some overlap?
[ ] Is top_k between 3 and 5?
[ ] Did you use the same embedding model for chunks and questions?
[ ] Does your prompt say "use only the context" and give an "I could not find this" line?
[ ] Do you have a distance cutoff?
[ ] Are you showing sources with every answer?

One more tip: write 10 test questions with known answers and run them after every change. That way you will know if a fix helped or made things worse.

Wrap-Up

Most RAG problems are not about the AI model. They come from how the text is cleaned, split, searched, and passed to the model. Fix those, and your answers get much better.

If you would like a working codebase to start from instead of fixing all of this yourself, I made a RAG chatbot source-code kit: RAG Source code.

Which of these problems hit you the most? Tell me in the comments, and I will try to cover it in the next part.

How to Build a "Chat With Your PDFs" App: A Simple RAG Guide

Dharanidharan — Tue, 29 Sep 2026 14:02:59 +0000

Ever wanted to upload a PDF and just ask it questions instead of scrolling through fifty pages? That is what a "chat with your PDF" app does, and it works using a technique called RAG (Retrieval-Augmented Generation).

In this guide, I will explain what RAG is in plain words, break down the pieces you need to build one, and walk through a simple working version step by step. By the end, you will understand exactly how these apps work under the hood, and you can build your own from here.

What Is RAG, in Plain Words?

RAG stands for Retrieval-Augmented Generation. That sounds complex, but the idea is simple.

Think of a smart friend who has read every page of your PDF but has a short memory. Every time you ask a question, your friend does not try to remember the whole document. Instead, they quickly flip to the exact pages that answer your question, read just those pages, and then answer you based on what they just read.

That is exactly what a RAG app does:

Retrieval — find the most relevant parts of the document for your question
Augmented Generation — hand those relevant parts to an AI model, which uses them to write a proper answer

Without RAG, an AI model only knows what it learned during training — it has never seen your PDF. RAG lets you "show" it the right pages of your document, right when it needs them, so it can answer questions about content it was never trained on.

The Building Blocks of a RAG App

A "chat with your PDF" app is made of five pieces, each doing one small job:

Step	What it does	Common tools
1. Extract text	Pulls the raw text out of the PDF	PyPDF2, pdfplumber
2. Chunk the text	Splits the text into small pieces (a few hundred words each)	Plain Python splitting, LangChain text splitters
3. Create embeddings	Turns each chunk into a list of numbers that capture its meaning	OpenAI embeddings, sentence-transformers
4. Store in a vector database	Saves those embeddings so they can be searched fast	FAISS, ChromaDB, Pinecone
5. Retrieve and answer	Finds the closest matching chunks to your question, sends them to an LLM, returns the answer	OpenAI, Anthropic, or any LLM API

Once you understand these five steps, you understand how every RAG app works. The fancy tools just do these steps for you automatically.

Building a Simple Version, Step by Step

Here is a minimal working example in Python. It will not be production-ready, but it will actually work, and it shows exactly what is happening at each step.

Step 1: Extract text from the PDF

import pdfplumber

def extract_text(pdf_path):
    text = ""
    with pdfplumber.open(pdf_path) as pdf:
        for page in pdf.pages:
            text += page.extract_text() + "\n"
    return text

Step 2: Split the text into chunks

def chunk_text(text, chunk_size=500):
    words = text.split()
    chunks = []
    for i in range(0, len(words), chunk_size):
        chunk = " ".join(words[i:i + chunk_size])
        chunks.append(chunk)
    return chunks

Step 3: Turn chunks into embeddings

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('all-MiniLM-L6-v2')

def embed_chunks(chunks):
    return model.encode(chunks)

Step 4: Store and search with a vector database

import faiss
import numpy as np

def build_index(embeddings):
    dimension = embeddings.shape[1]
    index = faiss.IndexFlatL2(dimension)
    index.add(np.array(embeddings))
    return index

def search(index, chunks, query_embedding, top_k=3):
    distances, indices = index.search(np.array([query_embedding]), top_k)
    return [chunks[i] for i in indices[0]]

Step 5: Ask the question and get an answer

def ask_question(question, chunks, index):
    query_embedding = model.encode([question])[0]
    relevant_chunks = search(index, chunks, query_embedding)
    context = "\n\n".join(relevant_chunks)

    prompt = f"""Answer the question using only the context below.

Context:
{context}

Question: {question}
Answer:"""

    # Send this prompt to any LLM API (OpenAI, Anthropic, etc.)
    # response = call_llm_api(prompt)
    # return response

Put these five pieces together — extract, chunk, embed, store, retrieve and answer — and you have a working "chat with your PDF" app.

Common Mistakes When You Build This

A few things that trip up most people the first time:

Chunks too big or too small. Too big, and the AI gets confused by irrelevant text mixed in. Too small, and it loses context. 300–500 words per chunk is a good starting point.
Forgetting to test with real questions. Try questions the document does not actually answer — your app should say "I don't know" instead of making something up.
Not handling scanned PDFs. If a PDF is a scanned image and not real text, pdfplumber will return nothing. You will need OCR (like pytesseract) for those.
Skipping overlap between chunks. If a sentence gets cut in half between two chunks, the answer can be incomplete. Adding a small overlap (30–50 words) between chunks fixes most of this.

Wrap-Up

That is the whole idea behind "chat with your PDF" apps: extract, chunk, embed, store, retrieve, and answer. None of the individual steps are hard on their own — the skill is in connecting them properly and handling the messy real-world cases, like bad formatting or scanned pages.

If you want to build your own version, the code above is a solid starting point. And if you would rather skip the setup and start from a working, tested codebase instead of debugging embeddings and vector search from scratch, I put together a ready-to-use RAG chatbot source-code kit: RAG source code.

Either way, I hope this helped you understand what is actually happening inside these apps. Let me know in the comments if you get stuck anywhere!

Fix LCP, INP & CLS in 2026: The Complete Core Web Vitals Guide (With Real Benchmarks)

Dharanidharan — Tue, 19 May 2026 13:00:00 +0000

TL;DR Core Web Vitals (LCP, INP, CLS) directly impact your SEO rankings, bounce rates, and conversions. This guide covers the fastest wins, proven optimization strategies across frontend/backend/CDN, stack-specific tips for Next.js, Laravel, and WordPress, and how AI is changing the performance game in 2026. Includes a full checklist.

Website performance optimization is no longer optional. If your Core Web Vitals are failing, you're silently losing rankings, conversions, and trust every single day.

I recently took a Laravel + Vue SaaS dashboard from an LCP of 4.1s down to 1.9s and the client saw a +22% increase in demo bookings within 30 days. In this guide, I'll walk you through exactly how I did it, and how you can apply the same techniques regardless of your stack.

I document what I build at dtechsolutions.

⚡ Quick Wins (Do These Right Now ~15 Minutes)

Before touching a single line of code, these fixes will move the needle immediately:

Convert your hero image to AVIF/WebP, targeting under 100KB (Squoosh is your best free tool here)
Add width and height to every <img> this alone eliminates most CLS issues instantly
Set long-lived cache headers for versioned assets:

Cache-Control: public, max-age=31536000, immutable

Put your site behind Cloudflare (even the free tier dramatically improves TTFB globally)
Baseline your scores using PageSpeed Insights and WebPageTest before you change anything you can't measure improvement without a baseline

Why Performance Actually Matters (Not Just for Devs)

Performance isn't a dev obsession it's a business metric:

Lower bounce rates: Mobile users abandon slow pages fast
Better SEO: Core Web Vitals are a Google Page Experience ranking signal
Higher conversions: Walmart, Pinterest, and Google/Deloitte research all link speed gains directly to conversion lifts
User trust: A fast site signals professionalism before a user reads a single word

With over 60% of global web traffic coming from mobile, and Google using mobile-first indexing, your mobile performance IS your ranking signal.

Core Web Vitals Explained (2026 Edition)

Largest Contentful Paint (LCP)

Measures how long the largest visible element (usually your hero image or headline) takes to fully render.

✅ Good: ≤ 2.5s
❌ Poor causes: slow TTFB, render-blocking resources, unoptimized images, client-side rendering delays

Interaction to Next Paint (INP)

Replaced First Input Delay in 2024. Measures your page's overall responsiveness to all user interactions.

✅ Good: ≤ 200ms
❌ Poor causes: heavy JS execution blocking the main thread

Cumulative Layout Shift (CLS)

Quantifies unexpected layout shifts that frustrating jump when content moves around as the page loads.

✅ Good: ≤ 0.1
❌ Poor causes: images without defined dimensions, late-loading fonts, dynamically injected content

Other Metrics Worth Watching

Metric	Target
Time to First Byte (TTFB)	< 800ms
First Contentful Paint (FCP)	< 1.8s
Total Blocking Time (TBT)	As low as possible

Real-World Results: Laravel + Vue SaaS Dashboard

Here's what a full optimization pass looked like on a recent client project:

Metric	Before	After
LCP	4.1s	1.9s
INP	320ms	120ms
CLS	0.18	0.03

What I actually did:

Converted hero image to AVIF
Implemented Redis caching for heavy DB queries
Removed 3 blocking third-party scripts
Deployed Cloudflare edge caching

Business outcome: +22% demo bookings in 30 days.

(Full case study on my portfolio)

Top Optimization Strategies

1. Images (Highest ROI Fix)

Images account for 50–75% of a page's total byte weight.

<!-- Use modern formats with fallback -->
<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" width="1200" height="630" 
       fetchpriority="high" alt="Hero">
</picture>

<!-- Lazy load below-fold images -->
<img src="product.webp" loading="lazy" width="400" height="300" alt="Product">

Key rules:

Always specify width + height (prevents CLS)
Use fetchpriority="high" on your LCP image
Use loading="lazy" on everything else

2. JavaScript Optimization

<!-- Non-critical scripts: defer or async -->
<script src="analytics.js" defer></script>
<script src="chat-widget.js" async></script>

Use code splitting so users only download what they need
Tree-shake unused imports especially painful in large component libraries
Audit every third-party script ruthlessly; chat widgets and ad tags are notorious offenders

3. Caching Strategy

# Versioned static assets cache forever
Cache-Control: public, max-age=31536000, immutable

# HTML pages always revalidate
Cache-Control: no-cache

For server-side: Redis or Memcached for DB queries, Varnish or CDN edge caching for rendered pages.

4. CDN Deployment

A CDN can cut TTFB by hundreds of milliseconds for international users. Cloudflare, Fastly, and Bunny.net all offer HTTP/3, edge-side rendering, and automatic image optimization.

5. Web Font Optimization

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap; /* Show fallback immediately */
}

Self-host fonts to eliminate third-party DNS lookups
Subset fonts to only the character sets you use
Ruthlessly cut font weight variants each one is another file

Stack-Specific Notes

Next.js

Prefer SSR/SSG for landing pages over pure CSR
Use next/image properly with sizes prop for responsive behavior
Avoid heavy client-side hydration on simple pages

Laravel

Enable route + config caching in production (php artisan config:cache)
Use Redis for session and query caching
Paginate large Blade loops never render 500 rows unpagged

WordPress

Remove page builders when possible (they bloat markup and JS significantly)
Use a lightweight theme (GeneratePress, Kadence) with disabled unused plugins
Implement full-page caching (WP Rocket, LiteSpeed Cache) + CDN

AI in Performance Optimization (2026)

AI is shifting performance work from reactive auditing to proactive, automated management:

AI-powered auditing: Tools like SpeedCurve and Calibre use ML to continuously monitor RUM data, detect regressions, and surface prioritized recommendations not just snapshots.

Predictive management: ML models can detect patterns like "LCP degrades by 200ms after every major bundle update" and trigger alerts or rollbacks before users are affected at scale.

AI image optimization: Platforms like Cloudinary's AI features intelligently crop, resize, and convert images based on network conditions and device capability dynamically.

Code analysis: Tools like Cursor and GitHub Copilot are increasingly capable of flagging expensive re-renders, N+1 queries, and blocking API calls during development, not post-production.

The future of performance is continuous, data-driven, and increasingly automated.

Common Mistakes to Avoid

Ignoring real user data Lighthouse runs on ideal conditions. Always combine with CrUX field data or your own RUM implementation.
Render-blocking <head> scripts anything without defer/async halts rendering.
Lazy-loading your LCP image the exact opposite of what you want; always fetchpriority="high" on the LCP element.
Neglecting TTFB a slow server nullifies everything. No amount of frontend optimization compensates for a 2s server response.
Treating performance as a one-time task new features, scripts, and content will degrade scores over time. Automate monitoring via Lighthouse CI.

The Performance Optimization Checklist

Images & Media

[ ] Served in WebP or AVIF
[ ] Responsive with srcset and sizes
[ ] All have explicit width and height
[ ] Off-screen images use loading="lazy"
[ ] LCP image uses fetchpriority="high"

CSS & JavaScript

[ ] Minified (Terser, cssnano)
[ ] Unused CSS removed (PurgeCSS)
[ ] Code-split and deferred
[ ] No render-blocking scripts in <head>

Caching & Delivery

[ ] Long-lived Cache-Control headers on static assets
[ ] CDN deployed
[ ] HTTP/2 or HTTP/3 enabled
[ ] Server-side or edge caching implemented

Fonts

[ ] font-display: swap on all custom fonts
[ ] Self-hosted or subsetted
[ ] Minimum number of weights/styles

Monitoring

[ ] Core Web Vitals monitored continuously
[ ] Real User Monitoring (RUM) implemented
[ ] Performance budget enforced in CI/CD

FAQ

What's a good Core Web Vitals score in 2026?
LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 on your most important pages.

Is PageSpeed Insights enough?
No. Use it for quick audits, but combine with WebPageTest for waterfall analysis and CrUX or RUM for real user data.

What gives the biggest speed gain, fastest?
In order: compress the hero image → remove heavy third-party scripts → deploy CDN + caching → reduce JS bundle size.

Closing Thoughts

Core Web Vitals aren't a checkbox they're a continuous competitive advantage. Every 100ms you shave off LCP is friction removed from your user's experience. Every layout shift you eliminate is trust you've earned before a user reads a word.

The strategies in this guide from image optimization and CDN deployment to AI-powered RUM analysis represent where performance engineering actually is in 2026. Start with the quick wins, work through the checklist, and automate monitoring so you don't have to do this again from scratch in six months.

If you want to see how I've applied this across client projects, my portfolio has a few case studies worth browsing.

Helpful tools mentioned:

— Built by Dharanidharan, full-stack developer specializing in performance-heavy SaaS.

If you found this useful, drop a ❤️ or bookmark it for your next performance audit. Have a metric that's stubbornly refusing to improve? Drop it in the comments happy to dig in.

Raycast in 2026: The Mac Launcher That Replaced 4 Apps in My Dev Workflow

Dharanidharan — Tue, 24 Mar 2026 13:30:00 +0000

Originally published on my blog: https://devtoolsreviewed.com/raycast-review/

If you're a developer who loses 30+ minutes a day switching between GitHub, Notion, Linear, and a dozen browser tabs this one's for you.

I've been running Raycast daily for eight months across multiple SaaS client projects. The honest result: I've cut app-switching time by an estimated 30–40 minutes per workday, and I've uninstalled Magnet, Paste, and a clipboard manager I was paying for.

Here's the full breakdown.

What Is Raycast, Actually?

Raycast is a keyboard-first command launcher for macOS that replaces ⌘ + Space. Think of it as a command palette for your entire machine and all the tools connected to it.

It handles:

App launching and file search
Clipboard history (searchable)
Window management
Text snippets/expansion
AI chat and commands
Deep integrations with GitHub, Notion, Linear, Vercel, Jira, and more
Custom shell/Python/Node script execution

Built by two ex-Facebook engineers who wanted "a command line for the GUI." It shows.

The Free Tier Is Already Better Than Spotlight

Before we even get to AI: the free tier alone replaces three tools most devs pay for.

Tool Replaced	Raycast Equivalent	Usual Cost
Spotlight	Launcher + file search	Free (already)
Magnet / Rectangle	Built-in window management	~$5–8 one-time
Paste / Clipboard Manager	3-month clipboard history	~$3–5/month

No credit card. No expiration. It just works from day one.

Developer Workflow: What This Looks Like in Practice

A typical morning without touching the mouse:

Trigger Raycast (⌥ Space or your custom hotkey)
Open GitHub extension → check open PRs on your repo
Jump to Linear → today's sprint tickets
Pull a code snippet from clipboard history (copied 3 days ago)
Run a custom script to spin up your dev server

That last one custom script commands is worth highlighting. You can write shell, Python, Node, or Ruby scripts and trigger them directly from the launcher:

#!/bin/bash

# @raycast.schemaVersion 1
# @raycast.title Open Dev Server
# @raycast.mode silent

cd ~/projects/my-app && npm run dev
open http://localhost:3000

One keystroke. Dev environment running. No terminal hunting.

Extensions Ecosystem: 1,000+ and Actually Useful

Extensions are built with a React-based API (Node.js compatible), published to a community store, and install in one click. No fiddling with configuration files.

Dev-focused picks:

GitHub — PRs, issues, repos without opening a browser
Linear — View and create tickets inline
Vercel — Trigger deployments, check project status
Homebrew — Search and install packages from the launcher
Docker — Manage containers directly
Ray.so — Generate beautiful code screenshots for sharing

Productivity layer:

Notion, Jira, Asana, Todoist, Google Drive, Slack, 1Password, Zoom

If an extension doesn't exist for your stack, you can build one. The docs are solid.

Raycast AI: Worth the Upgrade?

The Pro tier ($8/month billed annually) adds a full AI assistant baked into the launcher no browser tab required.

What you can actually do:

Quick AI: Ask a question, get an answer in the same interface you use to launch apps
AI Chat: Persistent ChatGPT-style interface for longer tasks architecture decisions, writing docs, debugging logic
AI Commands: Select any text on screen, run a command. "Explain this code." "Make this email more concise." Works system-wide across any app.
Custom Commands: Build your own prompts, bind them to hotkeys, run them repeatedly

Model support: OpenAI (GPT-4), Anthropic (Claude), Google (Gemini), Perplexity, Groq, Mistral, and more all through the same interface.

BYOK (Bring Your Own Key): If you already pay for API access, you can connect your own OpenAI, Anthropic, or Google keys. No per-message limits.

At $8/month, you're getting the full productivity suite plus multi-LLM AI access compared to $20/month for ChatGPT Plus alone.

Quicklinks: The Underrated Power Feature

Quicklinks let you create shortcuts to any URL with optional parameters. Sounds simple. Wildly useful.

Use cases:

Jump directly to your GitHub PR queue for a specific repo
Open your Vercel dashboard for project X
Link to a specific Notion database or doc
Internal tools, staging environments, anything URL-based

For managing multiple client projects, this is a game-changer. One launcher, every environment instantly accessible.

Raycast vs Alfred vs Spotlight (Quick Take)

Feature	Raycast	Alfred	Spotlight
Price	Free / $8/mo	Free / ~$35 one-time	Free
Extensions store	✅ 1,000+	✅ Limited	❌
AI integration	✅	❌	❌
Clipboard manager	✅	✅	❌
Window management	✅	❌	❌
Dev tool integrations	✅ Deep	✅ Moderate	❌
BYOK AI keys	✅	❌	❌

Alfred is excellent and the one-time Powerpack (~$35) is genuinely appealing if you hate subscriptions. But for developers on a modern stack (GitHub, Linear, Notion), Raycast's integration depth is harder to match.

Spotlight is fine for launching apps. It's not in the same category as either.

Honest Pros and Cons

✅ Pros

Free tier is legitimately feature-complete for most workflows
Fastest launcher on Mac opens before you finish typing
Extensions install in one click, no config files
Built-in AI across multiple LLMs on Pro
BYOK support for OpenAI, Claude, Gemini
Replaces multiple paid apps out of the box
Privacy-first: no input recording, local data storage

❌ Cons

macOS only (Windows is in beta, not feature-parity yet)
AI requires paid Pro plan
Advanced frontier models are an add-on on top of Pro
Extension quality varies popular tools are polished, niche ones less so
Can feel overwhelming until you build your personal workflow

Pricing Summary

Plan	Price	What's Included
Free	$0 forever	Launcher, 3-month clipboard, window management, snippets, 1,000+ extensions
Pro	$8/mo (annual)	Everything + AI, cloud sync, unlimited clipboard, custom themes
Advanced AI	Add-on to Pro	Frontier models (GPT-4, Claude Opus, Gemini Ultra)

Student discount: 50% off Pro with a verified university email.

Final Verdict

After 8 months of daily use: Raycast is the best Mac launcher available right now, and the free tier alone makes it worth installing today.

The upgrade from "never heard of it" to "I install this on every machine within the first five minutes" tends to happen within a week of use.

If you're a developer, indie hacker, or technical founder on Mac start with the free tier. You'll have a better workflow by end of day.

👉 Download Raycast Free →
👉 View Pro Features →

5 Web Dev Pitfalls That Are Silently Killing Your Projects (With Real Fixes)

Dharanidharan — Tue, 03 Mar 2026 13:00:00 +0000

Most of us have shipped something that "worked on my machine" only to watch it fall apart in production. The frustrating part? Beginner projects tend to fail in the same areas: mobile UX, performance, accessibility, and security. These mistakes are predictable which means they're fixable.

This post walks through five critical pitfalls I see constantly, with real code examples and actionable fixes you can apply today.

Pitfall #1: Breaking Your Site on Mobile

Over 60% of web traffic comes from mobile devices, yet most beginners test exclusively on a large monitor with DevTools occasionally set to "iPhone" mode. The result: horizontal scrolling, cramped spacing, and buttons too small to tap accurately.

The Fix

Go mobile-first with fluid layouts and proper touch targets:

/* ✅ Mobile-friendly approach */
.container {
  width: 100%;
  max-width: 1200px;
  padding: clamp(1rem, 5vw, 3rem); /* Scales between 16px and 48px */
  margin: 0 auto;
}

.button {
  padding: 12px 24px;
  min-height: 44px; /* Apple HIG + WCAG 2.2 requirement */
  min-width: 44px;
  font-size: 1rem;
}

Checklist

Test on real devices, not just DevTools
Use clamp() for responsive spacing
All touch targets should be minimum 44×44px
Avoid fixed widths use max-width instead
Check your layout at 320px, 768px, and 1440px

Pitfall #2: Shipping Slow Sites (Core Web Vitals Failures)

The three metrics that matter:

LCP (Largest Contentful Paint): under 2.5s
INP (Interaction to Next Paint): under 200ms
CLS (Cumulative Layout Shift): under 0.1

Images without dimensions are a classic CLS killer, and blocking scripts tank LCP.

The Fix

Prevent layout shift with explicit dimensions:

<!-- ✅ Prevents CLS and optimizes loading -->
<img
  src="hero.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 768px) 100vw, 1200px"
  alt="Hero image"
  width="1200"
  height="630"
  style="aspect-ratio: 1200 / 630;"
  loading="lazy"
  decoding="async"
>

Load non-critical scripts only when needed:

<!-- ✅ Load chat widget on first user interaction -->
<script>
  const loadChatWidget = () => {
    const script = document.createElement('script');
    script.src = 'chat-widget.js';
    script.defer = true;
    document.body.appendChild(script);
  };
  document.addEventListener('mousemove', loadChatWidget, { once: true });
</script>

Stop importing entire libraries:

// ❌ Imports everything
import _ from 'lodash';
import moment from 'moment';

// ✅ Tree-shakeable
import { sum } from 'lodash-es';

// ✅ Use native APIs
const formatted = new Intl.DateTimeFormat('en-US').format(new Date());

Checklist

Run Lighthouse before every deployment
Always specify image dimensions
Defer or async all non-critical scripts
Code split large JavaScript bundles
Monitor Core Web Vitals in Google Search Console

Last year I worked on a client project where the homepage CLS was 0.32 due to missing image dimensions. Fixing just three images dropped it to 0.05 and improved mobile engagement immediately.

Pitfall #3: Locking Out Users with Disabilities

Accessibility lawsuits are rising, but beyond legal risk you're genuinely locking out real users if your site isn't keyboard or screen reader friendly.

The Fix

Use semantic HTML with proper ARIA attributes:

<!-- ✅ Accessible form input -->
<div>
  <label for="email">Email Address</label>
  <input
    type="email"
    id="email"
    name="email"
    aria-required="true"
    aria-invalid="true"
    aria-describedby="email-error"
  >
  <span id="email-error" role="alert" style="color: #d32f2f;">
    Please enter a valid email address in the format: name@example.com
  </span>
</div>

Verify color contrast meets WCAG AA (4.5:1 ratio for body text):

/* ❌ Insufficient contrast (2.5:1) */
.text { color: #767676; background: #ffffff; }

/* ✅ WCAG AA compliant (4.6:1) */
.text { color: #595959; background: #ffffff; }

Make dropdowns keyboard-navigable:

function DropdownMenu() {
  const [isOpen, setIsOpen] = useState(false);

  const handleKeyDown = (e) => {
    if (e.key === 'Escape') setIsOpen(false);
  };

  return (
    <div onKeyDown={handleKeyDown}>
      <button
        aria-expanded={isOpen}
        aria-haspopup="true"
        onClick={() => setIsOpen(!isOpen)}
      >
        Menu
      </button>
      {isOpen && (
        <ul role="menu">
          <li role="menuitem"><a href="/profile">Profile</a></li>
          <li role="menuitem"><a href="/settings">Settings</a></li>
        </ul>
      )}
    </div>
  );
}

Checklist

Use semantic HTML (<button>, <nav>, <main>, <article>)
Every form input needs an associated <label>
Test with keyboard-only navigation
Install eslint-plugin-jsx-a11y to catch issues early
Test with NVDA (Windows) or VoiceOver (Mac)

Pitfall #4: Building Insecure APIs

The most common API vulnerability is BOLA Broken Object Level Authorization. It happens when an endpoint doesn't verify that the authenticated user actually owns the resource they're requesting.

// ❌ Anyone can access ANY order by changing the ID in the URL
app.get('/api/orders/:orderId', authenticate, async (req, res) => {
  const order = await db.orders.findById(req.params.orderId);
  res.json(order); // No ownership check!
});

The Fix

Always verify resource ownership:

// ✅ Ownership check
app.get('/api/orders/:orderId', authenticate, async (req, res) => {
  const order = await db.orders.findOne({
    id: req.params.orderId,
    userId: req.user.id // Critical
  });

  if (!order) return res.status(404).json({ error: 'Order not found' });

  res.json(order);
});

Add rate limiting to prevent brute force:

import rateLimit from 'express-rate-limit';

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  message: 'Too many login attempts, please try again later',
  standardHeaders: true,
  legacyHeaders: false,
});

app.post('/api/login', loginLimiter, async (req, res) => { ... });

Use short-lived tokens with secure storage:

// ✅ Short-lived access token + httpOnly refresh token
const accessToken = jwt.sign({ userId: user.id }, ACCESS_SECRET, { expiresIn: '15m' });
const refreshToken = jwt.sign({ userId: user.id }, REFRESH_SECRET, { expiresIn: '7d' });

res.cookie('refreshToken', refreshToken, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
});

res.json({ accessToken });

Checklist

Verify resource ownership in every API endpoint
Rate limit all public endpoints
Use short-lived JWTs (15 minutes max)
Store refresh tokens in httpOnly cookies
Validate and sanitize all user inputs

Pitfall #5: Blindly Trusting AI-Generated Code

AI tools like Copilot and ChatGPT are genuinely useful but they generate code that looks correct while hiding security holes and edge-case bugs. Here's a real example:

// ❌ AI-generated file upload looks fine, has a critical vulnerability
app.post('/api/upload', (req, res) => {
  const file = req.files.upload;
  file.mv(`./uploads/${file.name}`); // Path traversal attack!
  res.json({ success: true });
});

An attacker uploads a file named ../../../etc/passwd and you're in trouble.

The Fix

import path from 'path';
import { v4 as uuidv4 } from 'uuid';

const ALLOWED_EXTENSIONS = ['.jpg', '.jpeg', '.png', '.gif'];
const MAX_FILE_SIZE = 5 * 1024 * 1024; // 5MB

app.post('/api/upload', async (req, res) => {
  const file = req.files?.upload;

  if (!file) return res.status(400).json({ error: 'No file uploaded' });
  if (file.size > MAX_FILE_SIZE) return res.status(400).json({ error: 'File too large' });

  const ext = path.extname(file.name).toLowerCase();
  if (!ALLOWED_EXTENSIONS.includes(ext)) return res.status(400).json({ error: 'Invalid file type' });

  // Generate safe filename prevents path traversal
  const safeFilename = `${uuidv4()}${ext}`;
  const uploadPath = path.join(__dirname, 'uploads', safeFilename);

  await file.mv(uploadPath);
  res.json({ filename: safeFilename });
});

Checklist

Review AI-generated code line-by-line
Test edge cases AI tends to miss
Never accept code you don't fully understand
Run security linters (eslint-plugin-security)
Treat AI as an assistant, not a replacement for thinking

Your Action Plan for This Week

Run a Lighthouse audit on your main pages fix anything below 90
Install eslint-plugin-jsx-a11y and resolve violations
Audit your API endpoints for missing authorization checks
Review any AI-generated code from the past month
Test your site on a real mobile device, not just DevTools

Wrapping Up

These pitfalls affect developers at every level. The difference is that experienced developers have systems to catch them before they reach production automated Lighthouse CI, security scanning in PRs, accessibility linting in the editor, real device testing in QA.

You don't need years of experience to build secure, accessible, performant websites. You just need to know what to look for and now you do.

If you want more content like this, the original and more posts are on my blog: Dharanidharan's Solopreneur Blog.

What's the worst web dev pitfall you've run into? Drop it in the comments I'd love to hear how you fixed it.

Deploy Your Flutter Android App to Play Store in 2026: Step-by-Step Guide (With Code & Gotchas)

Dharanidharan — Wed, 04 Feb 2026 07:25:00 +0000

Flutter Play Store Deployment in 2026: targetSdk 35, AAB, CI/CD & Zero-Rejection Checklist.

If your Flutter app still follows a 2023 or 2024 deployment tutorial, it will likely get rejected on Google Play in 2026.

Google now enforces targetSdk 35 (Android 15), mandatory Android App Bundles (AAB), stricter permission reviews, and Play Integrity checks. Miss even one requirement, and your release stalls.

I’ve deployed multiple Flutter apps to production in 2025–2026, and this guide is the exact checklist I use to get apps approved on the first attempt—no outdated advice, no trial-and-error.

TL;DR — Flutter Play Store Deployment Checklist (2026)

✅ Flutter 3.38+

✅ compileSdk = 35, targetSdk = 35

✅ Android App Bundle (AAB only — APK not allowed)

✅ Upload keystore + enable Play App Signing

✅ Hosted privacy policy URL

✅ Data Safety & Permissions Declaration completed

✅ Internal testing before production release

✅ Crashlytics + Play Integrity configured

⏱️ Prep time: ~2–4 hours

⏳ Google review: 1–7 days

Here's the express route:

# Update your build.gradle to target API 35
# Generate keystore
keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA \
  -keysize 2048 -validity 10000 -alias upload

# Build release AAB with obfuscation
flutter build appbundle --release --obfuscate \
  --split-debug-info=build/app/outputs/symbols

# Upload to Play Console → Internal Testing → Production

Essential Links:

Timeline: 2-4 hours prep + 1-7 days Google review

Why Deploy in 2026? (The Stakes Are Higher Than Ever) 🚀

Google Play just dropped the hammer. As of August 31, 2025, all new apps and updates must target Android 15 (API level 35). Existing apps need API 34 minimum or they'll become invisible to users on newer Android devices. This isn't a suggestion it's a hard deadline that's already causing rejections.
I've deployed 5+ Flutter apps to production this year alone for clients across Tamil Nadu and South Asia, and let me tell you: the 2026 deployment landscape is very different from 2024.
Here's what changed:

AAB (Android App Bundle) is mandatory APKs won't cut it anymore
targetSdk 35 required for new submissions (API 34 for existing apps)
16KB memory page support for Android 15 compatibility
Play Integrity API replacing SafetyNet for security checks
Stricter privacy policy requirements (must be hosted, not PDF)

Flutter continues to be one of the most widely used cross-platform frameworks on Google Play, powering a large and growing number of production apps across startups and enterprises. But here's the kicker: many indie devs are getting rejected because they're using outdated deployment workflows from 2022-2023 tutorials. Don't be that dev.
This guide covers the complete 2026-compliant workflow with real code, common gotchas, and the exact configuration I use for client projects that go live in 48 hours.

Prerequisites ✅

Before we dive in, make sure you have:

Requirement	Version/Details	Why You Need It
Flutter SDK	3.38.6+ (latest stable)	Supports latest Android APIs
Android Studio	Ladybug 2024.2.1+	For SDK tools & emulators
Java/JDK	17+	Required for Gradle 8+
Google Play Console Account	$25 one-time fee	To publish apps
Privacy Policy URL	Hosted online	Play Store requirement
App Assets	Icon (512×512), Banner (1024×500)	Store listing

Who This Guide Is For

This guide is ideal if you are:

A Flutter developer preparing your first Play Store release
An indie dev tired of Play Store rejections
A freelancer shipping apps for clients
Migrating an existing app to targetSdk 35
Setting up CI/CD for Play Store deployments

If you just want a basic APK build — this is not that guide.

Quick Check:

flutter --version
# Flutter 3.38.6 • channel stable
# Dart 3.9.0 • DevTools 2.37.3

java --version
# openjdk 17.0.2 2022-01-18

If your Flutter version is below 3.24, upgrade immediately:

flutter upgrade
flutter doctor -v

Step 1: Prepare Your Flutter Project 📱

1.1 Update pubspec.yaml
Open pubspec.yaml and verify your version:

name: my_awesome_app
description: A production-ready Flutter app
version: 1.0.0+1  # Format: version_name+build_number

environment:
  sdk: '>=3.5.0 <4.0.0'

dependencies:
  flutter:
    sdk: flutter
  # Your other dependencies

Version scheme explained:

1.0.0 = version name (shown to users)
+1 = build number (internal version code)
Increment +1 → +2 → +3 for each upload
Major updates: 1.0.0 → 1.1.0 → 2.0.0

1.2 Configure build.gradle for API 35
Navigate to android/app/build.gradle and update:

android {
    namespace = "com.yourcompany.appname"  // Must match package
    compileSdk = 35  // ⚡ Required for 2026
    ndkVersion = "27.0.12077973"  // For native code

    defaultConfig {
        applicationId = "com.yourcompany.appname"
        minSdk = 24  // Supports 94%+ of devices
        targetSdk = 35  // 🔥 CRITICAL: Must be 35 for new apps
        versionCode = 1
        versionName = "1.0.0"
        multiDexEnabled = true
    }

    buildTypes {
        release {
            minifyEnabled = true  // Shrink code
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            signingConfig = signingConfigs.release
        }
    }
}

dependencies {
    implementation("androidx.core:core-ktx:1.13.1")
    implementation("androidx.appcompat:appcompat:1.7.0")
}

Pro tip: If you see "Namespace not specified" errors, add the namespace line inside the android block. This replaces the old package attribute in AndroidManifest.xml.

1.3 Update AndroidManifest.xml Permissions
Open android/app/src/main/AndroidManifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- ⚠️ Declare only permissions you actually use -->
    <uses-permission android:name="android.permission.INTERNET"/>

    <!-- For camera (only if needed) -->
    <uses-permission android:name="android.permission.CAMERA"/>

    <!-- For location (use COARSE first, FINE only if necessary) -->
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>

    <!-- For Bluetooth on API 31+ -->
    <uses-permission android:name="android.permission.BLUETOOTH_SCAN"
        android:usesPermissionFlags="neverForLocation" />
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>

    <application
        android:label="My Awesome App"
        android:icon="@mipmap/ic_launcher"
        android:enableOnBackInvokedCallback="true">  <!-- API 33+ -->

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop"
            android:windowSoftInputMode="adjustResize">

            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>

        </activity>
    </application>
</manifest>

Common gotcha: Google now rejects apps that request permissions they don't use. If you ask for ACCESS_FINE_LOCATION but only need city-level data, you'll get flagged. Remove unused permissions!

1.4 Test on API 35 Emulator
Create an emulator targeting Android 15:

# List available system images
flutter emulators

# Create API 35 emulator
avdmanager create avd -n Pixel_7_API_35 -k "system-images;android-35;google_apis;x86_64" -d "pixel_7"

# Launch and test
flutter emulators --launch Pixel_7_API_35
flutter run

Test critical flows: permissions, deep links, background services.

Step 2: Generate Signing Keys 🔐

Android requires cryptographic signing for release apps. Never lose these keys you can't update your app without them.

2.1 Generate Upload Keystore
On Mac/Linux:

keytool -genkey -v -keystore ~/upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 -alias upload

On Windows (PowerShell):

keytool -genkey -v -keystore $HOME\upload-keystore.jks `
  -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Follow the prompts:

Enter keystore password: [create a strong password]
Re-enter password: [same password]
What is your first and last name? [Your name or company]
What is the name of your organizational unit? [Engineering]
What is the name of your organization? [Your Company]
What is the name of your City or Locality? [Hosur]
What is the name of your State or Province? [Tamil Nadu]
What is the two-letter country code for this unit? [IN]

🔒 Security: Store the .jks file and password in a password manager (1Password, Bitwarden). Add to .gitignore:

# Keystore files
*.jks
*.keystore
key.properties

2.2 Create key.properties
In your Flutter project root, create android/key.properties:

storePassword=YourStrongPassword123!
keyPassword=YourStrongPassword123!
keyAlias=upload
storeFile=/Users/yourusername/upload-keystore.jks

⚠️ Warning: Never commit this file to Git! Add to .gitignore.
For CI/CD, use environment variables:

export KEYSTORE_PASSWORD="YourStrongPassword123!"
export KEY_PASSWORD="YourStrongPassword123!"
export KEY_ALIAS="upload"
export KEYSTORE_FILE="$HOME/upload-keystore.jks"

2.3 Configure Gradle Signing (Kotlin DSL)
Edit android/app/build.gradle:

// Add above the android block
val keystorePropertiesFile = rootProject.file("key.properties")
val keystoreProperties = Properties()
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(FileInputStream(keystorePropertiesFile))
}

android {
    // ... existing config ...

    signingConfigs {
        create("release") {
            storeFile = file(keystoreProperties.getProperty("storeFile") ?: "")
            storePassword = keystoreProperties.getProperty("storePassword")
            keyAlias = keystoreProperties.getProperty("keyAlias")
            keyPassword = keystoreProperties.getProperty("keyPassword")
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            // Enable R8 optimization
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

For older Groovy syntax (if using build.gradle not .gradle.kts):

def keystorePropertiesFile = rootProject.file('key.properties')
def keystoreProperties = new Properties()
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {
    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile file(keystoreProperties['storeFile'])
            storePassword keystoreProperties['storePassword']
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Step 3: Build App Bundle (AAB) 🚀

Time to create the production build. AABs are superior to APKs because Play Store dynamically optimizes downloads for each device.

3.1 Basic Release Build

# Clean previous builds
flutter clean

# Get dependencies
flutter pub get

# Build AAB (without obfuscation)
flutter build appbundle --release

Your AAB will be at: build/app/outputs/bundle/release/app-release.aab
Bundle size: Typically 15-30MB for a basic app. Check with:

du -h build/app/outputs/bundle/release/app-release.aab

3.2 Build with Obfuscation (Recommended)
Obfuscation makes reverse-engineering harder by scrambling class/method names. Critical for production apps.

flutter build appbundle --release \
  --obfuscate \
  --split-debug-info=build/app/outputs/symbols

What happens:

--obfuscate: Renames Dart code identifiers
--split-debug-info: Saves symbol maps for crash reports
Symbols go to build/app/outputs/symbols/ (keep these for Firebase Crashlytics)

Upload symbols to Firebase:

# After setting up Firebase Crashlytics
firebase crashlytics:symbols:upload \
  --app=YOUR_APP_ID \
  build/app/outputs/symbols

3.3 Optimize Bundle Size
Enable tree-shaking for icons:

# pubspec.yaml
flutter:
  uses-material-design: true
  # Only include icons you use
  fonts:
    - family: MaterialIcons
      fonts:
        - asset: fonts/MaterialIcons-Regular.otf

Or use this flag:

flutter build appbundle --release \
  --tree-shake-icons \
  --obfuscate \
  --split-debug-info=build/app/outputs/symbols

Advanced: Analyze bundle:

# Install bundletool
curl -LO https://github.com/google/bundletool/releases/download/1.15.6/bundletool-all-1.15.6.jar

# Analyze what's in your AAB
java -jar bundletool-all-1.15.6.jar build-apks \
  --bundle=build/app/outputs/bundle/release/app-release.aab \
  --output=app.apks \
  --connected-device

java -jar bundletool-all-1.15.6.jar get-size total \
  --apks=app.apks

Result example:

MIN_SDK=24 MAX_SDK=35
Total: 18.2 MB (arm64-v8a: 12.1 MB, armeabi-v7a: 6.1 MB)

3.4 Flavor Builds (Optional)
For dev/staging/prod environments:

# Build specific flavor
flutter build appbundle --release \
  --flavor production \
  --dart-define=API_URL=https://api.myapp.com \
  --dart-define=ENV=production

Step 4: Play Console Setup 🎨

Your app bundle is ready. Now let's create a compelling store listing.

4.1 Create App in Play Console

Go to Play Console
Click Create app
Fill in:
- App name: Max 30 characters (appears in store)
- Default language: English (United States) or your target market
- App or game: Select appropriate category
- Free or paid: Free (you can add in-app purchases later)
Accept Developer Program Policies and US Export Laws
Click Create app

4.2 App Content Declarations
Before uploading your AAB, complete these required sections:

Privacy Policy:

Must be a hosted URL (not PDF)
Use App Privacy Policy Generator
Or Termly for professional docs
Host on: GitHub Pages, your website, or Notion

Data Safety Section:

Navigate: Policy → App content → Data safety

Answer honestly:

Does your app collect user data? (Yes/No)
What types: Location, Personal info, Financial, etc.
Do you share data with third parties?
Is data encrypted in transit?

Pro tip: Most Flutter apps with Firebase collect at least device ID and crash logs. Disclose it!

Content Rating:

Policy → App content → Content rating

Complete the IARC questionnaire:

Violence: Does your app depict blood/gore?
Sexual content: Any romantic/sexual themes?
Profanity: Does it contain strong language?
Controlled substances: References to drugs/alcohol? Takes 5 minutes, generates ratings for ESRB, PEGI, USK, etc.

Target Audience:

Policy → App content → Target audience and content

Select age groups: 18+, 13-17, etc.
If targeting kids (under 13), stricter rules apply (COPPA)

4.3 Store Listing Assets
App Icon (512×512px):

PNG format, 32-bit with alpha
No rounded corners (Google adds them)
Tools: App Icon Generator

Feature Graphic (1024×500px):

Required for Play Store listing header
PNG/JPEG, max 1MB
No text that duplicates your app name
Canva template

Screenshots (Phone & Tablet):

Device Type	Minimum Required	Max Upload	Recommended Size
Phone	2	8	1080×2340 (9:16) or 1440×2560
7" Tablet	1 (if targeting tablets)	8	1920×1200 (16:10)
10" Tablet	1 (if targeting tablets)	8	2560×1600 (16:10)

Technical requirements:

Format: PNG or JPEG (24-bit, no alpha)
Min dimension: 320px
Max dimension: 3840px
Max dimension cannot be >2× min dimension
File size: 8MB max per image

Screenshot best practices (from 500+ apps analyzed):

First 3 screenshots are critical — shown in search results
Show actual UI, not marketing fluff
Add text overlays highlighting key features
Use device frames (optional but looks professional)
Portrait mode for phone screenshots
Showcase 5-7 core features across 6-8 screenshots

Tools for creating screenshots:

# Method 1: Android Emulator
# Run your app, then:
# Toolbar → Camera icon → Save screenshot

# Method 2: Physical device
adb shell screencap -p /sdcard/screenshot.png
adb pull /sdcard/screenshot.png

# Method 3: Automated (flutter_screenshot package)
flutter pub add flutter_screenshot
flutter test test/screenshot_test.dart --update-goldens

Add text overlays with App Mockup or Previewed

4.4 Store Listing Text

Short Description (80 chars max):

Boost productivity with AI-powered task management. Try it free!

Full Description (4000 chars max):
Structure it like this (tested on 100+ apps):

[Hook] Struggling to stay organized? Meet TaskFlow – the smart to-do app that learns your habits.

[Key Features]
✅ AI-powered task prioritization
✅ Seamless calendar sync (Google, Outlook)
✅ Voice commands & quick capture
✅ Cross-platform: Android, iOS, Web
✅ Offline mode with cloud sync

[Social Proof]
"TaskFlow doubled my productivity!" – ★★★★★ Review from Sarah M.
Featured in TechCrunch, Product Hunt #1 Product of the Day.

[Use Cases]
Perfect for:
- Students managing assignments
- Freelancers tracking client projects
- Busy parents juggling family schedules

[CTA]
Download now and reclaim your time. Free forever with premium upgrades.

[SEO Keywords]
todo app, task manager, productivity, GTD, project management

SEO tip: Include keywords naturally. Google Play indexes:

App title (30 chars) most important
Short description (80 chars)
Full description (4000 chars)

Localization:
If targeting India/South Asia:

Add Hindi, Tamil, Telugu translations
Often leads to significantly higher discoverability and conversion, especially in India and Southeast Asia, based on Play Console benchmarks and real-world launches.
Use Crowdin or hire on Upwork

4.5 Pricing & Distribution

Grow → Store presence → Pricing & distribution

Countries: Select carefully

Tier 1: USA, UK, Canada (high ARPU but competitive)
Tier 2: India, Brazil, Indonesia (massive user base)
Tip: Start with 50-100 countries, expand later

For Indian market targeting:

Include: India, UAE, Singapore, Malaysia
Optimize for 4G networks (bundle size <20MB)
Support UPI payments for in-app purchases

Step 5: Upload & Review 🎯

5.1 Create Internal Testing Track
Why internal testing first:

Faster review (~30 minutes vs 3-7 days)
Test with real users before public launch
Required for first-time Google Play apps (new developer accounts)

Steps:

Navigate: Release → Testing → Internal testing
Click Create new release
Upload AAB:
- Drag app-release.aab from build/app/outputs/bundle/release/
- Google scans for malware, API violations (~5 min)
Release notes:

Version 1.0.0
- Initial release
- Core features: X, Y, Z
- Supports Android 7.0+ (API 24)

Add testers (email addresses or Google Groups)
Click Review release → Start rollout to Internal testing

Testing link:

https://play.google.com/apps/internaltest/[YOUR_PACKAGE_ID]

Share with 5-10 beta testers. Collect feedback for 2-3 days.

5.2 Promote to Production
Once internal testing is stable:

Navigate: Release → Production
Click Create new release
Choose release type:
- Full rollout: 100% of users immediately
- Staged rollout: Start with 5% → 10% → 50% → 100% (safer)
Upload same AAB (or a newer build with +2 version code)
Release notes (user-facing):

What's new in v1.0.0:
🎉 Launch! Welcome to TaskFlow
✨ AI task suggestions
📱 Clean, intuitive interface
🔒 End-to-end encryption

Click Save → Review release

Automated checks run:

Security scan (malware, trojans)
API level compliance (targetSdk 35?)
Permissions review (do you justify camera access?)
Content rating match (does app match declared rating?)

If all green, click Start rollout to Production

5.3 Managed Publishing (Optional)

Release → Setup → Managed publishing

Enable this to control when updates go live:

Upload AAB
Google reviews it
Once approved, you choose the exact launch time

Great for coordinating with marketing campaigns.

5.4 Review Timeline & Common Rejections
Typical review times:

Internal testing: 30 minutes - 2 hours
Production (established accounts): 1-3 days
Production (new accounts): 3-7 days (stricter scrutiny)

Rejection reasons I've seen (and how to fix):

Issue	Reason	Fix
Content policy violation	App description mentions "coronavirus" without context	Remove health claims or link to WHO guidelines
Permissions misuse	Requested `ACCESS_FINE_LOCATION` for non-location feature	Remove unused permissions from AndroidManifest
Crashes on startup	Tested on Pixel 6 (API 33), app crashed	Test on multiple emulators; check logs with `adb logcat`
Misleading icon/screenshots	Icon resembles Google Photos app	Redesign to avoid brand confusion
Missing privacy policy	URL returns 404	Host privacy policy on GitHub Pages or website
API level too low	targetSdk 33 (needs 35 in 2026)	Update `build.gradle` to `targetSdk 35`
App not designed for families	Targets kids but has ads	Either remove ads or don't target kids under 13

Pro tip: If rejected, respond within 7 days with fixes. Use the "Appeal" button in Play Console if you think the rejection is wrong.

5.5 Post-Launch Monitoring
Once live, track these metrics:
Play Console Dashboard:

Installs: Daily downloads
Uninstalls: High rate = bad onboarding
Crashes: ANR (App Not Responding) rate should be <0.5%
Ratings: Aim for 4.0+ average

Firebase Crashlytics:

# Add to pubspec.yaml
firebase_core: ^3.9.0
firebase_crashlytics: ^4.5.0

# In main.dart
FlutterError.onError = FirebaseCrashlytics.instance.recordFlutterError;

Set up alerts:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp();

  // Pass all uncaught errors to Crashlytics
  FlutterError.onError = (errorDetails) {
    FirebaseCrashlytics.instance.recordFlutterFatalError(errorDetails);
  };

  // Catch async errors
  PlatformDispatcher.instance.onError = (error, stack) {
    FirebaseCrashlytics.instance.recordError(error, stack, fatal: true);
    return true;
  };

  runApp(MyApp());
}

Pro Tips & Gotchas ⚠️

Bundle Size Optimization
Problem: AAB is 45MB (Play Store recommends <20MB for emerging markets)
Solutions:
1. Compress images:

# Install imagemagick
brew install imagemagick  # Mac
sudo apt install imagemagick  # Linux

# Compress all PNGs in assets
mogrify -resize 1024x1024 -quality 85 assets/images/*.png

2. Use WebP format:

# pubspec.yaml
flutter:
   assets:
     - assets/images/hero.webp  # 75% smaller than PNG

3. Lazy load fonts:

# Don't bundle all Material Icons
uses-material-design: true
# Only include custom fonts you actually use

4. Analyze bundle breakdown:

flutter build appbundle --analyze-size
# Output: app-release-size-analysis.json

5. Enable app bundle deobfuscation:

// android/app/build.gradle
android {
   buildTypes {
       release {
           minifyEnabled true
           shrinkResources true  // Removes unused resources
       }
   }
}

Real example: Reduced client app from 38MB → 18MB using these techniques.

64-bit Requirement (Already Default)
All Flutter apps compile for both ARM32 and ARM64 by default since Flutter 2.x. Verify with:

flutter build appbundle --release
unzip -l build/app/outputs/bundle/release/app-release.aab | grep "lib/"

Should see:

lib/arm64-v8a/libflutter.so
lib/armeabi-v7a/libflutter.so

Play Integrity API (Replaces SafetyNet)
SafetyNet is deprecated. Use Play Integrity for anti-tampering:

# pubspec.yaml
dependencies:
  play_integrity: ^0.1.0

import 'package:play_integrity/play_integrity.dart';

Future<void> checkIntegrity() async {
  final token = await PlayIntegrity.requestIntegrityToken(
    nonce: 'YOUR_NONCE',
  );
  // Send token to your backend for verification
}

Backend verification (Node.js example):

const { google } = require('googleapis');

async function verifyIntegrity(token) {
  const playIntegrity = google.playintegrity('v1');
  const response = await playIntegrity.v1.decodeIntegrityToken({
    packageName: 'com.yourcompany.app',
    requestBody: { integrityToken: token }
  });

  // Check deviceIntegrity, appIntegrity, accountDetails
  return response.data.tokenPayloadExternal.deviceIntegrity.deviceRecognitionVerdict;
}

CI/CD with GitHub Actions
Automate deployments with GitHub Actions. Create .github/workflows/deploy.yml:

name: Deploy to Play Store

on:
  push:
    tags:
      - 'v*'  # Triggers on version tags like v1.0.0

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.38.6'
          channel: 'stable'

      - name: Install dependencies
        run: flutter pub get

      - name: Decode keystore
        run: echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 -d > android/app/upload-keystore.jks

      - name: Create key.properties
        run: |
          cat > android/key.properties << EOF
          storePassword=${{ secrets.STORE_PASSWORD }}
          keyPassword=${{ secrets.KEY_PASSWORD }}
          keyAlias=upload
          storeFile=upload-keystore.jks
          EOF

      - name: Build AAB
        run: |
          flutter build appbundle --release \
            --obfuscate \
            --split-debug-info=build/app/outputs/symbols \
            --build-number=${{ github.run_number }}

      - name: Upload to Play Console
        uses: r0adkll/upload-google-play@v1.1.3
        with:
          serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
          packageName: com.yourcompany.app
          releaseFiles: build/app/outputs/bundle/release/app-release.aab
          track: production
          status: completed
          inAppUpdatePriority: 3

Setup secrets in GitHub:

# Encode keystore to base64
base64 -i android/app/upload-keystore.jks | pbcopy

# Add to GitHub repo:
# Settings → Secrets and variables → Actions → New repository secret
# KEYSTORE_BASE64: [paste base64 string]
# STORE_PASSWORD: YourStrongPassword123!
# KEY_PASSWORD: YourStrongPassword123!
# SERVICE_ACCOUNT_JSON: [Google Cloud service account JSON]

Create Google Cloud service account:

Go to Google Cloud Console
Create new service account
Grant role: Service Account User
Create JSON key, download it
In Play Console: Settings → API access → Link service account

Version Management Strategy
Semantic versioning for Flutter:

1.2.3+45
│ │ │  └─ build number (increment every build)
│ │ └──── patch (bug fixes)
│ └────── minor (new features, backward compatible)
└──────── major (breaking changes)

Update script (scripts/bump_version.sh):

#!/bin/bash
# Usage: ./scripts/bump_version.sh patch

VERSION_TYPE=$1  # major, minor, or patch
PUBSPEC="pubspec.yaml"

CURRENT=$(grep "version:" $PUBSPEC | sed 's/version: //')
VERSION=$(echo $CURRENT | cut -d'+' -f1)
BUILD=$(echo $CURRENT | cut -d'+' -f2)

IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

case $VERSION_TYPE in
  major)
    MAJOR=$((MAJOR + 1))
    MINOR=0
    PATCH=0
    ;;
  minor)
    MINOR=$((MINOR + 1))
    PATCH=0
    ;;
  patch)
    PATCH=$((PATCH + 1))
    ;;
esac

NEW_BUILD=$((BUILD + 1))
NEW_VERSION="$MAJOR.$MINOR.$PATCH+$NEW_BUILD"

sed -i "" "s/version: .*/version: $NEW_VERSION/" $PUBSPEC
echo "Version bumped to $NEW_VERSION"

Usage:

chmod +x scripts/bump_version.sh
./scripts/bump_version.sh patch  # 1.0.0+1 → 1.0.1+2

Handling Native Code & Plugins
If using plugins with native Android code (camera, location, etc.):

Check plugin compatibility:

flutter pub outdated

Update all plugins:

flutter pub upgrade --major-versions

For plugins with native code, rebuild:

cd android
./gradlew clean
cd ..
flutter clean
flutter pub get
flutter build appbundle --release

Common plugin issues on API 35:

image_picker: Update to 1.0.7+
geolocator: Requires runtime permission requests
firebase_messaging: Update to 15.0.0+ for Android 13+ notifications

Testing with Firebase App Distribution
Before Play Store, distribute to QA team via Firebase:

# Install Firebase CLI
npm install -g firebase-tools

# Login
firebase login

# Deploy to App Distribution
firebase appdistribution:distribute build/app/outputs/flutter-apk/app-release.apk \
  --app 1:123456789:android:abcdef \
  --groups "qa-team" \
  --release-notes "Bug fixes for login flow"

My Portfolio Example 💼
Last month, I deployed a Flutter SaaS app for a Tamil Nadu-based logistics client went live in 48 hours from first commit to Play Store approval. The app handles real-time GPS tracking for 500+ delivery agents across Chennai, Bangalore, and Hosur.

Tech stack:

Flutter 3.38.6 + Riverpod for state management
Firebase (Auth, Firestore, Cloud Messaging)
Google Maps API with geofencing
Laravel backend with REST API

Challenges solved:

Optimized bundle size from 42MB → 19MB (critical for 4G networks)
Implemented offline-first sync with Hive
Passed Play Store review first try (no rejections!)

Client testimonial:

"Deployed faster than expected. The app handles peak traffic smoothly. Highly recommend!" — Ravi Kumar, CTO, SwiftLogistics

Need help with your Flutter app? I specialize in:

📱 End-to-end Flutter development (iOS + Android)
🚀 Play Store & App Store deployment
🤖 AI integration (ChatGPT, Gemini APIs)
☁️ Firebase + Laravel backends
🔧 DevOps & CI/CD setup

Based in Hosur, Tamil Nadu (serving clients across India, UAE, and USA).
Check my portfolio | Book a consultation

Conclusion & CTA 🎯

Flutter Play Store deployment in 2026 isn’t harder it’s less forgiving.
If you follow outdated tutorials, Google will reject your app.

If you follow this checklist, approval is usually boringly smooth.
Bookmark this guide before your next release — it will save you hours.

Follow this checklist:
✅ Update to Flutter 3.38.6+ and targetSdk 35
✅ Generate and secure signing keys
✅ Build optimized AAB with obfuscation
✅ Create compelling store listing (2-8 screenshots, privacy policy)
✅ Test on internal track first
✅ Monitor post-launch metrics (crashes, ratings)

Expected timeline:

Development: Varies (1 week - 6 months)
Deployment prep: 2-4 hours
Google review: 1-7 days
Total: ~48 hours for experienced devs

Resources:

👏 Found this helpful?

Clap (or ❤️) if this guide saved you hours of debugging
Follow me for more Flutter, Laravel, and AI integration tutorials
Share with your dev friends struggling with Play Store rejections

If you’re stuck with Play Store rejections or want a second review before publishing, I help teams ship Flutter apps without approval back-and-forth. Links below if useful. Let's chat! I'm available for:

Freelance projects (mobile apps, web apps)
Technical consulting (architecture, code reviews)
Training sessions (Flutter, Dart, Firebase)

📧 Contact: [dtechdigitalsolution@gmail.com]
🌐 Portfolio: [dtechsolutions]
💼 LinkedIn: [linkedin.com/in/yourprofile]
🐦 X(Twitter): [@dtech_solution]

Last updated: January 2026. Tested with Flutter 3.38.6, Android Studio Ladybug, targetSdk 35.

Keywords: flutter deployment, play store, android app, AAB, targetSdk 35, flutter tutorial, indie dev, freelance developer, Hosur developer, Tamil Nadu, app publishing 2026

💬 What part of Play Store deployment has caused you the most trouble?

Permissions? targetSdk upgrades? Rejections?
Drop a comment I reply to every serious dev question.

FAQs
Q: Can I use an APK instead of AAB?
A: For Play Store, AAB is mandatory. APKs only work for direct distribution (website downloads, enterprise apps).

Q: How long does Play Store review take for first-time developers?
A: 3-7 days (stricter scrutiny). Established accounts: 1-3 days.

Q: Do I need a Mac for Android deployment?
A: No! Android deployment works on Windows, Mac, or Linux. (iOS needs Mac + Xcode.)

Q: What if I lose my keystore file?
A: You cannot update your app. You'd have to publish as a new app with a new package name. Back it up!

Q: Can I change my app's package name after publishing?
A: No. Package name (com.company.appname) is permanent. Choose wisely!

Q: How do I add in-app purchases?
A: Use the in_app_purchase plugin. Configure products in Play Console → Monetize → Products.

Q: My app was rejected for "Permissions Declaration Form". What now?
A: For sensitive permissions (location, camera, contacts), Google requires a form explaining why you need them. Fill it in Play Console → App content → Permissions declaration.

Enjoy this guide? More Flutter & Laravel content coming soon. Stay tuned! 🚀

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan — Tue, 27 Jan 2026 07:35:00 +0000

If you're a React developer stuck in tutorial hell with no real portfolio, this guide is for you.

In this post, I’ll show exactly how I built a React portfolio website using Vite and Tailwind CSS that helped me land ₹1.2L+ ($1,400+) in freelance projects in under three weeks.

No paid tools. No fancy frameworks. Just a clean, deployed portfolio that clients could actually visit.

Step 1: Vite + React Portfolio Setup Using Vite

Forget Create React App. Vite is lightning fast and gets you coding in under a minute.

npm create vite@latest my-portfolio -- --template react
cd my-portfolio
npm install
npm run dev

Your dev server fires up at localhost:5173. Clean the boilerplate from App.jsx and you're ready to build.

Step 2: Tailwind CSS Configuration

Install Tailwind and set up the config properly. This is crucial for customization later.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Update tailwind.config.js to scan your components:

export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {
      colors: {
        primary: '#3b82f6',
        dark: '#1e293b',
      },
      fontFamily: {
        sans: ['Inter', 'sans-serif'],
      },
    },
  },
  plugins: [],
}

Add Tailwind directives to src/index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Step 3: Build Reusable Components

Here's the secret sauce: component-driven architecture makes iterations painless. I built a ProjectCard component that I reused 6 times across my portfolio.

const ProjectCard = ({ title, description, tech, liveUrl, githubUrl, image }) => {
  return (
    <div className="bg-white dark:bg-dark rounded-lg shadow-lg overflow-hidden hover:shadow-xl transition-shadow">
      <img src={image} alt={title} className="w-full h-48 object-cover" />
      <div className="p-6">
        <h3 className="text-2xl font-bold mb-2">{title}</h3>
        <p className="text-gray-600 mb-4">{description}</p>
        <div className="flex flex-wrap gap-2 mb-4">
          {tech.map((t, i) => (
            <span key={i} className="px-3 py-1 bg-blue-100 text-blue-800 rounded-full text-sm">
              {t}
            </span>
          ))}
        </div>
        <div className="flex gap-4">
          <a href={liveUrl} className="text-primary hover:underline">Live Demo</a>
          <a href={githubUrl} className="text-gray-700 hover:underline">GitHub</a>
        </div>
      </div>
    </div>
  );
};

Usage in your main component:

<div className="grid md:grid-cols-2 lg:grid-cols-3 gap-6">
  <ProjectCard 
    title="E-commerce Dashboard"
    description="Admin panel with real-time analytics"
    tech={['React', 'Tailwind', 'Chart.js']}
    liveUrl="https://demo.example.com"
    githubUrl="https://github.com/user/project"
    image="/project1.png"
  />
</div>

Step 4: Deploy to Vercel (Under 5 Minutes)

Push your code to GitHub, then:

Go to vercel.com and sign in with GitHub
Click "Import Project" and select your repository
Vercel auto-detects Vite just click "Deploy"

Your site goes live at yourname.vercel.app. For custom domains, add them in project settings (I bought a .tech domain for ₹800/year).

Netlify alternative: Drag-drop your dist folder after running npm run build. Both platforms offer free hosting with SSL.

Step 5: Portfolio Showcase Strategy

You can see my live implementation at dtechsolutions.tech, but here's what actually got me clients:

Hero section: Clear headline ("Full-Stack Developer specializing in React + Node.js")
3-4 strong projects: Quality over quantity. Include live demos and GitHub links
Tech stack badges: Visual representation using icons from react-icons
Contact form: Used Formspree for free form handling

Tech Stack Used in This React Portfolio

React 18
Vite 5
Tailwind CSS 3
Vercel (Deployment)
Formspree (Contact Form)
GitHub (Version Control)

Pros and Cons of This Stack

| Pros                                             | Cons                                         |
| ------------------------------------------------ | -------------------------------------------- |
| Tailwind's utility classes enable faster styling | Initial learning curve for Tailwind syntax   |
| Component reusability saves hours                | Need to set up dark mode manually            |
| Vite's hot reload is incredibly fast             | Smaller ecosystem vs Next.js                 |
| Free deployment on Vercel/Netlify                | Client-side rendering only (no SEO benefits) |
| Works perfectly on mobile out of the box         | Larger bundle size than vanilla CSS          |

Results: From Zero to Paid Gigs

Within 2 weeks of posting my portfolio:

Reddit (/r/forhire, /r/webdev): 2 gigs (₹40K total) by commenting with portfolio link on "looking for developer" posts
LinkedIn: 2 gigs (₹80K total) by posting my portfolio with "#opentowork" and tagging "React" + "Web Development"
Average project: ₹30K for landing pages, ₹50K for dashboards

Indian clients loved seeing actual deployed projects vs just GitHub repos. The Vercel links proved I knew deployment, not just coding.

Tips for Indian Freelancers

Price in rupees initially: Start at ₹20-30K for simple projects, scale up as you gain testimonials
Leverage time zone: Mention "same-day turnaround" for clients in IST zones
Add Razorpay/UPI: Show you can integrate Indian payment gateways
Use Indian hosting examples: If targeting local clients, mention experience with Indian servers/compliance
Network on LinkedIn: Indian startup founders are very active there engage with their posts

Final Thoughts

You don't need a fancy tech stack or months of preparation. React + Tailwind + Vercel got me from zero to earning within 3 weeks. The key was shipping something imperfect but functional, then iterating based on client feedback.
Stop planning, start building. Your first freelance gig is one portfolio away. Want to see the final result? Here's my portfolio: dtechsolutions.tech

Tech stack: React 18, Tailwind CSS 3.4, Vite 5, Vercel
Build time: 7 days
Cost: ₹0 (free tier everything)
Live portfolio: dtechsolutions.tech

FAQ: React Portfolio for Freelancing

How many projects should a React portfolio have?

3–4 high-quality, deployed projects are better than many unfinished ones.

Is Vite good for building a React portfolio?

Yes. Vite is fast, lightweight, and perfect for small to medium React projects.

Do clients care about GitHub or live demos?

Clients prefer live demos. GitHub is secondary unless they are technical.

If this helped you, drop a ❤️ or comment “portfolio” and I’ll share my repo structure.