DEV Community: Gulshan Yadav

MisarReach MCP Server: Find Leads, Run Outreach, and Manage Your Pipeline from an AI Assistant

Gulshan Yadav — Mon, 05 Oct 2026 15:45:11 +0000

Sales work is research-heavy and tool-heavy: you find a company in one tab, verify the email in another, pull the contact into your CRM, draft the outreach in a third tool, then come back to track replies. None of it is in one place.MisarReach's MCP server brings the entire top-of-funnel workflow into your AI assistant. With 27 tools, 5 prompts, and 4 resources, you can go from "find me 50 seed-stage SaaS founders in Europe" to a live outreach sequence — without switching apps.## What you can do*Lead discovery and enrichment- discover_companies — search by industry, geography, size, funding stage- search_leads — find people by role, company, location, or keyword- enrich_lead — pull job title, LinkedIn, email, phone, and company details- verify_emails — validate deliverability before sending- score_leads — score a list against your ideal customer profileLists and organisation- Create and sync lead lists- Preview leads before sending them to a campaignOutreach sequences- preview_message — draft and preview a personalised message before sending- send_to_campaign — add verified leads to an active multi-channel sequence- Never auto-sends without an explicit send_to_campaign callPipeline management- List, create, and update deals- Move deals between pipeline stages- get_pipeline — see your full pipeline at a glanceAutopilot mode*- start_autopilot — hand off a lead list to a configured sales agent- get_autopilot_status — check what it's doing, cancel if needed## Install in 30 seconds### Claude Code

bashclaude mcp add misarreach -- npx -y @misarreach/mcp@latest

Claude Desktop / Cursor / VS Code / any stdio client

json{ "mcpServers": { "misarreach": { "command": "npx", "args": ["-y", "@misarreach/mcp@latest"], "env": { "MISARREACH_API_KEY": "mrk_your_key_here" } } }}

Smithery

bashnpx -y @smithery/cli install misar/misarreach-mcp --client claude

Remote (no local install — ChatGPT, any HTTP client)

json{ "mcpServers": { "misarreach": { "type": "streamable-http", "url": "https://api.misar.io/reach/mcp", "headers": { "Authorization": "Bearer mrk_your_key_here" } } }}

Get your API key at reach.misar.io/settings/api-keys.## AuthenticationRun the login tool (opens the MisarReach OAuth page) or set MISARREACH_API_KEY. Every tool call without a key returns the exact URL to get one.## Links- npm: @misarreach/mcp- GitHub: Misar-AI/misarreach-mcp- Smithery: smithery.ai/server/misar/misarreach-mcp- Docs: docs.misar.io/reach/mcp- MisarReach: misarreach.com

Misar.Blog MCP Server: Write, Publish, and Grow a Blog from Your AI Assistant

Gulshan Yadav — Mon, 05 Oct 2026 15:44:16 +0000

Every blogger knows the friction: the ideas happen in conversation, but publishing them means opening a separate CMS, wrestling with metadata, resizing images, and then coming back to analytics in yet another tab.

Misar.Blog's MCP server collapses that workflow. With 23 tools, 8 prompts, and 5 resources, you can take a post from idea to published — and track how it performs — without leaving your AI assistant.

What you can do

Writing and publishing

Create drafts and update articles
Publish when you're ready (the server never auto-publishes without an explicit call)
Search your existing articles before writing something you've already covered
Research a topic: the research_topic tool pulls background context so you can write informed drafts faster

SEO and titles

Generate SEO-optimised title suggestions from a working title or topic
generate_title_seo returns structured metadata you can paste directly

Cover images

generate_cover_image produces a cover from your article title — no Figma needed

Series management

Group related posts into a series
Add articles to a series after the fact

Newsletters

List subscribers and send newsletter issues from the same MCP session

Analytics

get_analytics_summary — top posts, traffic trends, referral sources
Reactions per article so you know what's resonating

Install in 30 seconds

Claude Code

claude mcp add misarblog -- npx -y @misarblog/mcp@latest

Claude Desktop / Cursor / VS Code / any stdio client

{
  "mcpServers": {
    "misarblog": {
      "command": "npx",
      "args": ["-y", "@misarblog/mcp@latest"],
      "env": { "MISARBLOG_API_KEY": "mbk_your_key_here" }
    }
  }
}

Smithery

npx -y @smithery/cli install misar/misarblog-mcp --client claude

Remote (no local install — ChatGPT, any HTTP client)

{
  "mcpServers": {
    "misarblog": {
      "type": "streamable-http",
      "url": "https://www.misar.blog/api/mcp",
      "headers": { "Authorization": "Bearer mbk_your_key_here" }
    }
  }
}

Get your API key at misar.blog/dashboard/settings/api-keys.

Authentication

Run the login tool (opens the Misar.Blog OAuth page) or set MISARBLOG_API_KEY. Every tool returns setup instructions when no key is present.

MisarMail MCP Server: Run Your Entire Email Operation from an AI Assistant

Gulshan Yadav — Mon, 05 Oct 2026 15:44:15 +0000

Email has always been the channel that takes the most time to get right. Writing subject lines, segmenting audiences, watching deliverability metrics, cleaning lists, setting up automations — all of it happens in a separate tool, disconnected from wherever you actually think and write.

MisarMail's MCP server changes that. With 55 tools, 8 prompts, and 4 resources, you can run your entire email operation without leaving your AI assistant.

What you can do

Send and manage email

Send transactional and marketing email
Search, read, and archive inbox conversations
Draft replies and handle categorisation

Campaigns

List, create, send, and track campaigns
A/B test subject lines and content — pick a winner when the data is in
Schedule by timezone or optimal send-time prediction

Contacts and lists

Import, update, and score contacts
Build segments from behaviour and attributes
Trigger or pause automations

Deliverability

Run a full deliverability audit (SPF, DKIM, DMARC, blacklists, warm-up ceiling)
Check inbox placement by provider
Monitor domain health over time

Analytics

Revenue attribution per campaign
Open, click, unsubscribe, and bounce timelines
Monetisation and subscriber growth reports

Install in 30 seconds

Claude Code

claude mcp add misarmail -- npx -y @misarmail/mcp@latest

Claude Desktop / Cursor / VS Code / any stdio client

{
  "mcpServers": {
    "misarmail": {
      "command": "npx",
      "args": ["-y", "@misarmail/mcp@latest"],
      "env": { "MISARMAIL_API_KEY": "msk_your_key_here" }
    }
  }
}

Smithery

npx -y @smithery/cli install misar/misarmail-mcp --client claude

Remote (no local install — ChatGPT, any HTTP client)

{
  "mcpServers": {
    "misarmail": {
      "type": "streamable-http",
      "url": "https://api.misar.io/mail/mcp",
      "headers": { "Authorization": "Bearer msk_your_key_here" }
    }
  }
}

Get your API key at mail.misar.io/developers.

Authentication

Run the login tool (opens the MisarMail OAuth page — nothing to copy) or set MISARMAIL_API_KEY. Every tool call without a key returns setup instructions; nothing silently fails.

Try it without credentials

Tools/list works with no API key — you can inspect every tool before authenticating:

npx -y @misarmail/mcp@latest <<< '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Freelance vs Full-Time Developer in 2026: The Math Nobody Does

Gulshan Yadav — Tue, 29 Sep 2026 13:30:00 +0000

For the first six months of my freelance career, my hourly rate was $11.40.

I remember the exact number because I had produced it with a spreadsheet and a straight face. I took the monthly income I wanted, divided it by the hours I assumed I would work — forty a week, like a job — and arrived at a rate that any client with a calculator could see was absurd. It priced me as a widget. And for a while, I got widget-level work at widget-level rates, because when you quote low, the only clients who bite are the ones shopping by price, and they treat you accordingly.

Then a client paid me $4,500 for a flat-fee project that took about forty hours of real work. I did the division twice. That single job had priced me at over a hundred dollars an hour — not because I suddenly worked harder, but because I had charged for the outcome instead of the time.

That one contract rewired my career. But it also taught me the uncomfortable truth sitting under the whole freelance-versus-full-time debate: almost nobody does the complete math. They compare the headline numbers — the salary on the offer letter, the rate on the invoice — and ignore everything in between. The benefits. The taxes. The utilization. The months with no income. This article is the math I wish someone had shown me before I quit my first job. It is a money story, and it ends with a framework you can run on a spreadsheet in twenty minutes.

The $11.40-an-Hour Lesson

I was two years into engineering when I started taking freelance work at night, and I had no pricing model whatsoever. My method was fear-based: I picked a number low enough that a client could not possibly say no, then I silently doubled my hours to make up for it. $11.40 an hour was the result. The projects took exactly as long as they took, so I subsidized my own learning while a client paid less than a plumber's visit for a week of software work.

The psychological cost was bigger than the money. Low rates attract price-shopping clients, and price-shopping clients are the hardest to work with — they extract scope, they argue invoices, and they leave harsh reviews when reality does not match their expectations of a "cheap" developer. For six months I blamed the market. The market was fine. My pricing was the bug.

Here is the math of that trap, written down the way I should have written it on day one:

$11.40/hr × 40 billable hours/week = $456/week gross
Non-billable work is real: discovery calls, quoting, invoicing, chasing payments — about 20% of my week
Effective rate: roughly $9.50/hr for every hour I actually worked
Taxes, hardware, software, and internet: about 30% off the top
Net: around $6.50 an hour to build someone else's product

That is the slide. The headline number looks small but survivable; the effective number, after unbillable hours and costs, is what quietly destroys you. And because the client was happy and the work kept coming, I had zero pressure to fix it until the math forced the issue.

The $4,500 Flat Fee

The turning point was a logistics company in Dubai that reached out about a dashboard. It felt too small to be real — a dispatch view, some role-based access, a couple of integrations. I had learned one lesson by then: never quote by the hour on something I had done before. So I quoted a flat fee: $4,500.

It took forty hours across two weeks. I remember staring at the effective rate — north of a hundred dollars an hour — and feeling the exact moment my pricing model cracked. What changed was not skill. It was that I charged for the outcome — the working dashboard, the uptime, the dispatchers who stopped toggling between five spreadsheets — instead of the input.

But here is the honest part of the story, the part nobody tells you on the freelancing YouTube channels: a single $4,500 project does not make you a successful freelancer. It makes you dangerously optimistic. The real question was whether that rate could survive the full accounting — the gaps between projects, the months with one invoice and thirty days of waiting, the clients who paid sixty days late. So I finally did the accounting I had been avoiding since $11.40. That is the math nobody does.

The Math Nobody Does

Here is the framework. It has four lines, and you have to compute all four before you can honestly compare the two columns.

Line 1 — The true hourly rate

Salary is not the number on your offer letter, and an hourly rate is not the number on your invoice. Convert both to the same unit: dollars per hour of actual productive work.

For a full-time job, that means dividing total compensation — salary plus benefits value — by the hours you actually sit and do deep work. For freelance, it means dividing your real annual income by your real billable hours, not by forty times fifty-two. Most comparisons die right here, because people compare $95,000 against $80/hr and call it a day.

Line 2 — The benefits line

An employer pays for health insurance, retirement matching, paid leave, and often training, hardware, and software. In 2026 those are worth roughly 25–35% of your salary. As a freelancer you buy every one of them out of your own post-tax income, which is strictly worse than having a portion paid pre-tax. I have seen freelancers celebrate earning what their old salary paid — and quietly drop their insurance because it felt too expensive, which is a cost that shows up later and hurts more.

Line 3 — The utilization tax

Full-time, you get paid for forty hours even in a week where you shipped nothing. Freelance, you get paid only for the hours you invoice. Realistic utilization for a solo developer is 20–28 billable hours in a forty-hour week, because you are also the marketer, the accountant, the contract writer, and the collections agency. The honest way to read any hourly rate is: rate × realistic billable hours × 48 working weeks. Everything else is fiction.

Line 4 — The volatility tax

Full-time income is steady; freelance income is a random walk with payment delays. Gaps between contracts, a client who pays sixty days late, a dry January, a platform that changes its fee structure overnight. You have to hold a runway against this, and the runway has an interest rate: it is capital sitting in a bank account instead of compounding.

The Worked Example

Let me put 2026 numbers on it. Rough US figures for a mid-level remote developer; adjust the tax rates and benefits to your country, the shape of the math does not change:

Line	Full-time (mid-level, remote)	Freelance (solo)
Headline	$95,000 salary	$80/hr, 25 billable hrs/wk
Gross annual	~$120,000 incl. ~$25k benefits	25 × 48 wks × $80 = $96,000
Paid leave	~5 weeks, paid	0 — every week off is unpaid
Benefits cost	Subsidized by employer	Out of pocket, post-tax
Utilization	Paid for 40 hrs regardless	~62% of working hours billed
Admin & gaps	None	~20% of time un-billable + gaps between contracts
Effective annual	~$88k stable, after taxes and benefits	~$58–64k volatile, after taxes, insurance, and gaps

The conclusion is uncomfortable and most people never want to hear it: on an apples-to-apples basis, the $95,000 full-time job with benefits beats the $80/hr freelance rate. Not because $80 is low — because a solo freelancer does not get to bill forty hours a week, does not get paid for downtime, and pays for benefits with after-tax money. The hourly rate only wins when you do what I did on the Dubai dashboard: stop selling hours and start selling outcomes at a multiple of your hourly rate.

The Realization

After the $4,500 job, I made the spreadsheet do the honest thing. The realization has three parts:

Freelancing wins only when you price the outcome, consistently — not occasionally. One value-priced project is an accident. The framework only works if every invoice carries that logic, because the utilization tax and the volatility tax eat accidental wins alive.
Full-time is not the loser in this comparison. For the first several years of a career, full-time almost always wins, because you are trading a small, steady number today for compounding learning, mentorship, and brand that show up as a much larger number later. Freelance is a sales job first and an engineering job second, and a developer who is not ready to sell has not left a job — they have left a salary.
The deciding number is not the rate; it is the effective hourly, after all four lines. I have met developers earning $60/hr who are poorer than colleagues at $40/hr because their utilization is 30% and they have no benefits. I have also met freelancers billing less per hour than their old salary equivalent who are genuinely better off, because they work a real 25 billable hours and stop.

The number that decided it for me was the effective line in the spreadsheet: to genuinely beat a $95k full-time package as a solo developer, I needed roughly $70–80k of actual billable income after taxes and downtime — which, at realistic utilization, meant an effective rate above $100/hr on every invoice, not on the occasional one. The Dubai project proved the ceiling was real. The framework proved it was repeatable. That is when I quit.

The Application

Here is how I now walk any developer through the decision — including the ones who email me stuck at "I'm cheap, so clients won't leave."

The decision rule

Run all four lines before you decide anything. In order:

Compute the true hourly for your full-time option. Total compensation ÷ real deep-work hours. If you have no offer, use your current salary.
Add 25–35% for benefits to the salary column. That is the number the freelance column has to beat.
Compute realistic freelance income. Rate × your honest billable hours per week × 48 weeks. If you do not know your utilization yet, use 22 hours — that is the observed average for solo devs, and optimism is how people underprice themselves.
Subtract taxes, insurance, and a gap allowance — assume at least two to four weeks of unpaid gaps a year, and sixty-day payment cycles on real clients.
Ask the runway question: do you have six months of expenses saved? If no, the debate is over — take the job, build the runway, and revisit in twelve months. This single rule has saved more developers from bankruptcy than any pricing advice I have ever given.

Then apply the three-question sanity check:

Can you price outcomes, not hours? If your only pricing skill is hourly, full-time pays better. Project and value pricing is a skill, not a mood.
Can you sell? Freelance income is sales income with engineering attached. If you are not comfortable quoting, following up, and being told no, you have not left a job — you have left a salary.
Can you tolerate sixty-day payment cycles and a dry January? The math on paper assumes the money arrives. The money does not always arrive on time.

What I Did With It

The framework gave me a contract with myself. I did not quit on the high of the $4,500 job — I quit on the spreadsheet, months later, when two conditions were true at once: I had six months of expenses in the bank, and I had two signed clients on retainer, not one project and a hope. The three-client rule came next: I have never gone a full freelance week without either a retainer or a signed project in the pipeline, because the volatility tax is only survivable if you actively smooth it.

I still use the same four lines today, even though I now run a company instead of a solo practice. The decisions are bigger, but the math is identical: convert everything to effective hourly, count the benefits you would otherwise pay for yourself, measure utilization instead of guessing it, and hold a runway against the gaps. Every developer I have walked through this has found the same thing I did — the answer is rarely "freelance makes you rich." It is usually "full-time is the better business for now, and here is the number you need to cross to change your mind."

The honest ending is this: neither lane is superior, and the people who tell you otherwise are usually selling a course. Full-time buys you stability, compounding skill, and other people's infrastructure to learn on. Freelance buys you leverage — but only after you learn to price outcomes, measure utilization, and survive the gaps. Run the four lines, build the runway, and let the spreadsheet make the decision you are too attached to make yourself. That is the math nobody does, and it is the only math that is actually yours.

*Gulshan Yad

The Best Free AI Tools for Students in 2026 — Tested Honestly

Gulshan Yadav — Tue, 29 Sep 2026 02:30:00 +0000

Last month, a first-year engineering student asked me a question that sounded simple and was not: "Which AI tools do I actually have to pay for?"

She had watched a YouTube video telling her she needed three paid subscriptions — a chatbot, a research tool, a tutor — to survive university. At roughly $60 a month, that is more than most Indian students spend on food. She was looking for permission to spend money she did not have.

My answer, before I did any work, was "none." But I have spent seven years building AI systems in production, and I know that gut answers about tools are how students waste the most money and the most study time. So instead of trusting my opinion, I spent a month testing the free tiers of the major AI tools against the five jobs students actually do: drafting essays, researching with citations, understanding long documents, solving math and coding problems, and revising for exams. I used only what a free account gives you, I kept notes on every failure, and I scored each tool on four criteria. This is what survived.

The Criteria

Every tool below was tested against the same four questions:

Criterion	What I actually checked
Accuracy	Does it get facts right, admit uncertainty, and avoid inventing citations?
Free limits	What is genuinely usable on the free plan, measured in hours of daily student work — not marketing copy?
Privacy	What happens to your data on the free tier, and can you control or delete it?
Study fit	Is it useful for essays, research, documents, math, coding, or revision — not just pleasant to chat with?

One hard rule governed the whole test: if a tool only became useful after I hit a paywall, it did not make the list. I also ran every tool on the same tasks — the same essay prompt, the same 40-page PDF, the same calculus problem — so the scores are comparisons, not vibes.

The Tools, Tested Honestly

1. ChatGPT (Free)

OpenAI's free tier is the default answer for a reason: it is the most rounded tool here. On the free plan you get a capable model for everyday work — not the flagship reasoning model, but more than enough for essay drafts, concept explanations, and debugging homework.

Accuracy: Strong on common topics, weaker on recent events. It hallucinates rarely but confidently; during testing it invented a plausible-sounding citation out of thin air. For a student, that is the single worst failure mode in this entire list, because a fake source in an essay is worse than no source.
Free limits: Generous for daily use. The caps exist and tend to bite exactly when you need the tool most — exam week — but for routine work they rarely interrupt. File uploads, web search, and a limited amount of image generation are included.
Privacy: Your conversations train the model unless you opt out, and chat history is not private. Fine for homework, wrong tool for anything sensitive.
Study fit: 9/10 across the board — the Swiss Army knife. Its weakness is that it does not force you to learn; it is very good at producing the answer you should be finding yourself.

2. Google Gemini

Gemini is the tool I underestimated the most. The free tier carries the largest context window in this comparison, and for students that one fact changes everything.

Accuracy: Good, with web grounding baked in — it tells you when it is pulling from the web, which is useful for essays. Its math and code reasoning have improved a lot; it still occasionally rounds incorrectly on multi-step algebra.
Free limits: The most generous here. A wide request window, plus native Google integration — your Drive documents, lecture notes, and slides are searchable from the prompt. A 2M-token context means you can paste an entire textbook and ask questions about it, and it will remember the whole thing.
Privacy: Same caveat as ChatGPT — free-tier data is used for training. The toggle is prominent, but the default is sharing.
Study fit: The long context is the killer feature. Summarize a full semester of lecture slides, cross-reference chapters, ask follow-ups without re-uploading. No other tool on this list does that on a free account.

3. Claude (Free)

Anthropic's free tier is the best pure writer here, which matters if your degree is essay-heavy.

Accuracy: Claude is the most careful with language and the most likely to say "I don't know" — a rare and valuable trait in this category. It produced the most natural, least AI-smelling prose of the group.
Free limits: The tightest. Daily message caps are real, and you will hit them in the middle of a long study session. Some of Claude's best features, like Projects, sit behind the paid tier.
Privacy: Anthropic ships stricter data-handling defaults than most of its competitors. Still assume free-tier conversations are reviewed.
Study fit: An editing and writing powerhouse, a weak all-rounder. Use it for essays and to improve your own writing — treat the others as research tools and this one as the wordsmith.

4. Grok

Grok's free tier is real but thin — a limited number of requests to a capable model, aimed at current events rather than coursework.

Accuracy: Strong on recent, web-fresh topics. Noticeably weaker on structured academic tasks; it was the least reliable at math and citation handling in my test runs.
Free limits: The smallest quota in this list. The model is designed around real-time information, not long study sessions, and it shows.
Privacy: X is a public-adjacent product. Assume anything you paste is training data. Do not paste private documents here.
Study fit: A news and current-affairs tool, not a study tool. It is genuinely useful for "what just happened" research for an essay or debate prep, then you go back to the others for the actual work.

5. Perplexity

Perplexity is a search engine that answers in sentences, with citations — and its free tier is the best research companion in this comparison.

Accuracy: The highest citation transparency of the group. Every answer links its sources, which students need for essays and which makes hallucination far easier to catch.
Free limits: A limited number of Pro searches per day, but the basic search tier is effectively unlimited for daily research. The limit hits when you want deep research mode, not ordinary questions.
Privacy: Standard search-engine data collection; fewer training-data concerns than the chat apps, but treat it as a search engine, not a vault.
Study fit: The citation trail is the win. When I asked it to compare spaced versus massed practice and retention, it returned a summary with sources I could actually cite. That is the difference between research and guessing.

6. NotebookLM

NotebookLM is the most underrated tool on this list, and the one I now recommend to every student who asks. It is source-first: you upload your own PDFs, slides, and notes, and the AI answers strictly from those sources.

Accuracy: The best in this test, because it cannot drift outside your documents. Every claim is grounded in what you uploaded, which makes it effectively hallucination-proof for your own course material.
Free limits: Generous for personal use — multiple notebooks and a reasonable upload volume before it nudges you toward a paid plan.
Privacy: Your sources stay inside your own notebooks; far more contained than pasting lecture notes into a chat window.
Study fit: This is the exam machine. Upload your course pack, and it produces grounded Q&A, study guides, and audio overviews of your own lectures. In testing, I built a revision guide from a 40-page PDF in under three minutes, and every fact traced back to the source. That single behavior beats every general chatbot for actual studying.

7. Khanmigo

Khanmigo is Khan Academy's AI tutor, now free for students and teachers. It is not a general assistant — it is a tutor that refuses to hand you the answer.

Accuracy: Very high on the subjects it covers, because it is scaffolded on Khan Academy's curriculum. Math, physics, and programming explanations are structured for learning, not for producing output.
Free limits: Free for students and teachers, which removes the main barrier entirely.
Privacy: Education-sector data handling, designed for minors — a stronger default than the general tools.
Study fit: The anti-ChatGPT. When you ask it a math problem, it asks you questions back — the Socratic method in software. In testing it forced me to work through the steps instead of copying them, which is precisely what makes it better for learning and worse for "just give me the answer."

8. Misar.ai

I built this one, so I am going to be careful to be honest about it. Misar.ai is a model-agnostic AI workspace that routes to multiple free models behind one interface, so you can compare how different models answer the same question instead of trusting a single one. I am including it in the list because, for its purpose, it tests well — and excluding it would be dishonest about the landscape.

Accuracy: As accurate as the underlying models, which means it inherits their strengths and their hallucinations. It does not add accuracy on its own; what it adds is comparison.
Free limits: A genuinely free tier. The whole reason it exists is to give students a real free option that does not quietly charge them later.
Privacy: Self-hosted routing; your queries are not sold to train a third-party model. On privacy it scored higher than the big three.
Study fit: Its honest value is the comparison feature — when one model gives you a suspicious answer, you run the same prompt on two others and see where they diverge. That is a genuinely good habit for catching hallucinated citations. Its con: it is a younger product with fewer polish features than the billion-dollar tools, so if you want one polished assistant out of the box, ChatGPT or Gemini is the safer default.

The Comparison Table

Job	Use this	Why
Research with citations	Perplexity	A source trail you can actually cite
Studying from your own PDFs	NotebookLM	Grounded, hallucination-resistant
Learning math properly	Khanmigo	Forces you to think, not copy
Whole textbooks and long slides	Gemini	Massive free context window
Essays and polished writing	Claude	Best prose, honest about uncertainty
One all-rounder to rule them	ChatGPT Free	Best balance of everything
Cross-checking suspicious answers	Misar.ai	Run the same prompt across models

The Verdict

After a month of testing, here is the honest summary. No tool won everything, and the tools that won are not the ones the marketing pages would have you believe.

The biggest surprise was NotebookLM. It is the least hyped tool on this list and the most clearly useful for actual studying, because grounding your AI in your own documents eliminates the hallucination problem at the source. The second surprise was that the most famous free tier — ChatGPT — is still the best all-rounder, which is exactly why OpenAI keeps it free: it is the front door to everything else they sell.

The Decision Rule

Stop choosing tools by hype and choose by task. Before you open any AI tool, ask one question: what am I actually trying to do?

If you are trying to learn: Khanmigo or NotebookLM. The tool should slow you down, not speed you up.
If you are trying to research: Perplexity or Gemini. You need sources and context, not vibes.
If you are trying to write: Claude or ChatGPT. You need prose, then a critical pass.
If you are trying to verify: Misar.ai. Run the same prompt across models and look for divergence.

And the rule that matters more than any tool choice: do not pay for an AI tool until you have exhausted the free tier of every tool in this list. The most expensive mistake students make is buying a $20 subscription to replace a free tool that already does the job. In my testing, the only tools whose paid tiers I genuinely missed were Claude's Projects and Perplexity's deep research — and both are conveniences, not necessities.

One honest caveat before you rely on this list: free tiers change quarterly, and by the time you read this, one of these tools will probably have tightened a quota. When that happens, switch. The tools are interchangeable; the habit — testing a tool against your real work instead of its marketing — is not.

*Gulshan Yad

Freelance Developer Pricing: The Framework That Stops the $11/hr Slide

Gulshan Yadav — Mon, 28 Sep 2026 13:30:00 +0000

I once charged a client $11.40 an hour to build software. Not early in a recession, not as a student internship — as a working freelancer in my mid-career, pricing myself into a hole because I had no framework for what my time was worth. The client was thrilled. They were getting a senior engineer for the price of a fast-food shift. I was doing the mathematical equivalent of paying rent with pennies.

That $11.40 number lived in my head for years as a failure. Then I rebuilt my entire pricing approach around the question that actually broke the slide: what is this work worth to the client, not what does it cost me to produce? This article is that story and the framework that came out of it — the same one I now teach freelancers who write to me stuck at "I'm cheap, so clients won't leave."

The Slide: How a Developer Ends Up at $11.40/hr

Let me be honest about how I got there, because the path is more common than anyone admits.

It started the normal way: my first few freelance jobs came from bidding on a marketplace, and I had no reputation, no portfolio, and no idea what other people charged. I read the bios of developers charging $15, $20, $30 an hour and assumed that was the market. I undercut to win. A client who had been burned by overpriced agencies saw a competent developer at a rock-bottom rate and hired me instantly. That felt like validation. It was a trap.

The math of the trap is brutal and most freelancers never write it down:

$11.40/hr × 40 billable hours/week = $456/week gross
Non-billable time is real: discovery calls, quoting, invoices, chasing payments — about 20% of my week
So effective rate: about $9.50/hr for every hour I actually worked
Taxes, health insurance, hardware, software, internet: roughly 30% off the top
Net: about $6.50/hr to build someone else's product

That is the entire anatomy of the slide. The hourly number looks small but survivable; the effective number — after unbillable hours and costs — is what quietly destroys you. And because the client was happy and the work was coming in, I had zero pressure to fix it until the math caught up.

The Realization: Hourly Pricing Is a Ceiling You Install Yourself

The turning point was a project where I saw the client's numbers. A logistics company hired me to automate a reporting flow that a finance analyst rebuilt by hand for two days every month. The automation took me three weeks and I billed it at my then-rate. When the client mentioned offhand that the automation "probably saves us about a day of this guy's time every month," I did the arithmetic in my head: the value to them was roughly $18,000 a year in saved labor — and I had priced it at a fraction of that because I had priced my hours, not the outcome.

That was the realization, and it has three parts:

Hourly pricing assumes the client should pay for your effort. They want to pay for their outcome. No client ever bought "three weeks of React." They bought "our analysts stopped rebuilding this report by hand."
Hourly pricing penalizes you for being fast. The better you get, the fewer hours you bill, the less you earn — a built-in incentive to be slow and mediocre. It is the only profession where getting better at your job pays you less.
The number itself invites negotiation. A client will happily push $11.40/hr to $10.50/hr, because it is a small number. They will not push a $7,500 project price to $6,500 without real consideration, because it is a decision, not a reflex.

The framework that follows is simple to state and hard to practice: stop selling hours, start selling projects priced against the value of the outcome. Everything else is scaffolding around that one move.

The Framework: Four Steps That Broke the Slide

Step 1: Stop Quoting an Hourly Rate to New Clients

From the day of the realization, I stopped putting an hourly number on the table. When a client asks "what's your rate?", the answer is not a number — it is a redirection: "I don't quote by the hour, because the price depends on the project. What are we solving?"

This is not a trick. It is the honest statement that the price should reflect the outcome. The moment you say a number, you are in the hourly frame, and the slide starts again. Refuse the frame politely and firmly every time.

The Discovery Call That Prices the Outcome

The call where you gather the value is the highest-leverage hour in freelance pricing, and it is also where most freelancers waste it by demoing their skills instead of extracting the client's economics. I structure every call the same way now:

What is the pain? Ask for the last time the problem hurt. "When did you last lose money or time to this?" The answer gives you the story to anchor the price.
What does it cost them today? Work the number out loud: the analyst's two days a month, the failed export, the manual QA. If you can get them to say the number, you have your anchor.
What happens in a year if it is fixed? This is the number you price against. You are not asking for a commitment; you are asking them to value the outcome themselves, which is exactly what you will quote against.
What is out of scope? Before you give a price, define what you are not doing. Ambiguity here is the seed of every future argument.
Then, and only then, the number. One number, stated plainly, and silence. The first person to speak after a price loses the negotiation, so do not fill the silence with your own justifications.

The call converts the hourly frame into a value frame before a single price is spoken. By the time you quote, the client has already told you what the outcome is worth to them — you are just taking a fair share of it.

Step 2: Price the Project Off the Value, Then Anchor It

Before quoting, I run a version of this calculation with every client:

What does this solve, and what does the problem cost them today? (The reporting flow: 2 days/month of an analyst's time ≈ $18k/year.)
What does the solution save or earn them per year?
What is the one-year value? Take a share of it. A fair starting point is 10–20% of the first year's value for a one-off build.

For the reporting project, that meant a price of roughly $1,800 to $3,600 — versus the $300 I would have quoted by hours. The anchor is the value to them, and it is defensible because it is their number, not your effort estimate.

Step 3: Scope Control — Write the Change Order Into the Contract

The reason freelancers fear project pricing is scope creep: the client adds "one small thing" after another and the fixed price becomes a lie. The framework handles this before it starts.

Every project price includes an explicit scope, and every out-of-scope request gets a change order with its own price. The rule I use: anything that changes the deliverable, the integrations, or the data model is out of scope and priced separately. I have a client-visible line in every contract: "Small text edits and bug fixes are included. New features, new screens, or new integrations are priced as change orders." That one sentence has saved me more money than any rate increase I ever negotiated.

The honest truth is that clients respect scope discipline. The ones who fight it were going to burn you regardless, and the change-order clause surfaces them early.

A concrete example of how this plays out: I priced a dashboard build at a fixed project price. Two weeks in, the client asked for "just a mobile view" of the same dashboard. Under hourly pricing I would have sighed and done it. Under scope control, I sent a one-line change order — mobile responsive pass, one screen, $400, four days — and they approved it within a day. The request was legitimate and the client was happy to pay; what they wanted was to know the cost before it happened, not a freelancer absorbing it and silently resenting them. Scope control is not about squeezing the client. It is about making cost visible, which is what clients actually want.

Step 4: Raise Based on Evidence, Not Guilt

Once you are out of the hourly frame, raising prices is mechanical. I keep a simple ledger per client: total billed, the outcome delivered, and whether they renewed or referred. When I have three closed projects with outcomes and renewals, I raise the next quote by 20–30%. Not because I feel worth more — because I have evidence the work is worth more to them.

The $11.40/hr freelancer could not justify a raise because the only evidence was hours. The project-priced freelancer has outcome numbers. The raise writes itself.

Retainers: The Exit From Project Chasing

The framework gets you out of the hourly slide, but projects are still a treadmill — every month you are selling the next one. The step after project pricing is retainer pricing: a fixed monthly fee for a fixed monthly scope, usually a maintenance package or a recurring improvement budget.

A retainer is just project pricing with a subscription. You quote a monthly number against a monthly outcome: "$1,500 a month for the dashboards to stay live, monitored, and improved — includes two change orders a month, anything more is quoted." The client gets predictability, you get revenue that does not depend on your next proposal landing.

The numbers matter here: one retainer at $1,500 a month is more predictable than four project wins a year, because the retainer does not reset to zero every time you invoice. My current practice is roughly two-thirds recurring revenue on retainers and one-third one-off projects — and the one-offs are now priced from a position of existing income, which removes the desperation that caused the slide in the first place.

What If My Market Won't Pay That?

The most common objection I hear when I teach this is the honest one: "that works in your market, my clients won't pay it." I have been there, and the evidence says otherwise — with one real caveat.

The evidence: in every market, there are clients who buy on price and clients who buy on outcome. The price buyers will never pay a project price; they are the $11.40/hr economy, and losing them is the point, not the cost. The outcome buyers exist in every niche — they are the ones who have been burned by cheap freelancers who under-delivered and disappeared. They are not hard to find; they are hard to talk to until you stop leading with an hourly rate that screams "cheap and replaceable."

The real caveat: early on, when you have zero proof of outcomes, you will take some below-value work to build the evidence. That is not the slide — it is an investment with an exit date. My rule is two or three such projects maximum, each one chosen because it produces a number you can show to the next client. After that, the evidence exists, and under-pricing is no longer strategy; it is fear.

The Numbers That Came Out of It

Here is what the framework did to my actual income, and I keep these numbers honest because the whole point is that this is not magic:

Phase	Pricing model	Effective hourly result
The slide	$11.40/hr marketplace bids	~$6.50/hr net
After realization	Fixed project, value-anchored	~$45/hr equivalent
After scope control	Fixed projects + change orders	~$75/hr equivalent
After evidence raises	Outcome-priced, 20-30% step raises	~$110/hr equivalent

The rate tripled twice. Not because I became three times better in eighteen months — because I stopped selling hours, started selling outcomes, and let scope control stop the leaks that hourly pricing was designed to ignore. My calendar got lighter at the same time, because project pricing also means you can take fewer, better clients.

The Pricing Exercise You Can Do Today

If you are stuck on an hourly number, do this in one sitting — it takes twenty minutes:

Write down your last three projects and what they actually did for the client (saved hours, earned money, prevented a cost).
Put a one-year value on each. Be conservative; guess the lower bound.
Price each at 10–20% of that one-year value. That is your project number. Compare it to what you actually billed. The gap is the size of the slide you are still in.
Write your change-order line and put it in your next contract verbatim: out-of-scope features are priced separately.
Pick the next client and quote the project number — not an hourly rate. Say the frame out loud: "I price this against what it's worth to you, not against my hours."

The first time you quote a value-anchored project price, your mouth will go dry and the client might pause. That pause is normal. What you are asking them to do is treat you as a professional selling an outcome instead of a commodity selling time. Clients who value that will pay it. Clients who need a body at $11.40/hr will keep sliding — let them.

I still remember the $11.40 number, but not as a failure anymore. It is the baseline that makes every later number mean something. The framework is not about getting rich; it is about building a pricing system that stops the slide, survives scope creep, and raises itself on evidence. Price the outcome, scope it tightly, raise on proof — and let the hourly race to the bottom belong to someone else.

The decision rule I use on every single quote, and the one I want you to steal: if a client negotiates by asking "what's your hourly rate?", you are still inside the old frame. The move is never to answer the number. It is to return to value — "I price against what this is worth to you, not against my hours" — and let that sentence do the selling. Every time I have said it out loud, the conversation got easier, and the price got better.

*Gulshan Yad

Free Medium Alternative with AI Discovery: Writing Where Algorithms Find You

Gulshan Yadav — Mon, 28 Sep 2026 02:30:00 +0000

In 2023 I could publish a technical article on Medium and trust the platform's algorithm to push it to a few thousand readers within a week. By the end of 2025 that number had collapsed. The same quality of writing started earning a fraction of the views, because the distribution had quietly moved: people were no longer discovering articles the way they used to. They were asking ChatGPT, Perplexity, Gemini, and Google's AI Overviews — and those systems cite what they can index, verify, and attribute, not what is trending inside a platform feed.

That shift changed where I publish. I stopped optimizing for a platform algorithm and started optimizing for the systems that decide what an answer engine will cite. This article compares five free writing platforms on exactly that axis: how well your work gets discovered by AI answer engines, not just by a human feed. The platforms are Medium, Substack, Hashnode, Ghost (self-hosted), and the AI-first platform I now publish my deep-dives on, misar.blog.

One clarification up front: when I say "AI discovery," I mean two distinct things, and it is worth keeping them separate. The first is indexability — can the platform's pages be crawled, parsed, and cited by answer engines at all? The second is citation-worthiness — does the platform's structure, speed, and metadata make an answer engine more likely to cite you than a competitor? Platforms score very differently on each, and the difference is where writers waste months.

The Criteria

Criterion	Why it matters	Weight
AI indexability	Can answer engines crawl and parse your pages cleanly?	30%
Citation likelihood	Structure, speed, and authority signals that earn citations	25%
Owned audience & SEO	Do you keep the relationship and the search equity?	20%
Monetization	Can you earn directly, or must you leave the platform?	15%
Cost & portability	What does free cost, and how hard is leaving?	10%

Scores are out of 10. I have published on every platform in this list within the last two years, and I check my own citations in ChatGPT, Perplexity, and Google AI Overviews routinely.

Medium

Medium still has the largest human audience, but on the AI-discovery axis it is the most complicated case of the group.

AI indexability: 7/10. Medium articles are indexed and get cited by answer engines — older, high-authority articles especially. If the answer engines know a topic, a Medium article is often among the first sources they consider.
Citation likelihood: 6/10. Paywalled and metered articles are a real problem. Answer engines frequently downgrade or skip content they cannot fully access, and Medium's paywall is exactly the kind of gating that reduces citation confidence.
Owned audience & SEO: 4/10. You keep none of the relationship. Readers are Medium's, the domain is Medium's, and your search equity lives on Medium's URLs.
Monetization: 8/10. The Partner Program still pays for engaged reading time. For writers who already have a Medium following, it is the easiest money in the group.
Cost & portability: 5/10. Free to write, but your audience and metrics are locked in, and exporting does not move search equity.

Verdict: still the largest audience, and still the worst platform for building something you own.

Substack

Substack's distribution is email-first, which is its superpower for owned audiences and its weakness for AI discovery.

AI indexability: 6/10. Articles on Substack domains are indexed normally and do get cited, but the platform does not engineer for it. Public posts are fine; paywalled posts are invisible to crawlers, which matches Medium's problem.
Citation likelihood: 6/10. Substack's structure is simple and parseable, but there is nothing in the platform that makes an answer engine prefer it. Your citations depend entirely on your content and your domain authority.
Owned audience & SEO: 7/10. You own the subscriber list — that is the real asset. But the SEO lives on a Substack subdomain, so search equity is not yours.
Monetization: 9/10. Native paid subscriptions are the strongest monetization in the group.
Cost & portability: 7/10. Free, with easy email export. Re-hosting the articles after export is manual but straightforward.

Verdict: the right platform for a newsletter business; not the platform to build AI-citation equity.

Hashnode

Hashnode is a developer-first blogging platform with solid SEO defaults and an active community feed.

AI indexability: 8/10. Clean HTML, correct structured data, and a public feed make Hashnode pages easy for crawlers to parse. Their articles appear in answer-engine citations regularly.
Citation likelihood: 7/10. The structure is good — headings, code blocks, and metadata are all first-class — but the platform does not actively optimize for citation the way an AI-first platform does.
Owned audience & SEO: 9/10. You own the content, and with a custom domain you own the rankings. This is the strongest owned-SEO story among the non-self-hosted options.
Monetization: 6/10. No native revenue share; you monetize through sponsorships or your own products.
Cost & portability: 9/10. Free with your domain, and export is painless.

Verdict: the best conventional blog for developers who want AI citations and full ownership.

Ghost (Self-Hosted Free)

Self-hosted Ghost is the ownership maximum, and it scores surprisingly well on AI discovery because the answer engines reward exactly what self-hosting forces you to have.

AI indexability: 10/10. Your own domain, your own server, clean semantic HTML, and full control over robots and structured data. If the content is good, this is as citeable as a site gets.
Citation likelihood: 9/10. Fast pages, clear authorship, and no paywall gating mean answer engines cite self-hosted Ghost sites readily. My highest-citation articles have run on self-hosted infrastructure.
Owned audience & SEO: 10/10. Everything is yours — domain, data, rankings, subscribers.
Monetization: 8/10. Native paid memberships are built in.
Cost & portability: 6/10. Free software, but you own the operations: SSL, updates, backups, uptime. That cost is real and monthly.

Verdict: the best citeability money (and effort) can buy, if you can run a server.

misar.blog

The AI-first platform I now publish my deep-dives on. It is free, supports your own domain, and is engineered from the ground up for the discovery model that replaced the feed: answer engines.

AI indexability: 9/10. Sitemap-first architecture, fast static rendering, and clean metadata are the defaults, not an afterthought. Everything is designed to be crawled and parsed cleanly.
Citation likelihood: 9/10. This is the platform's whole reason to exist — no paywalls gating content, structured posts, and pages that render instantly for crawlers. My deep-dives there are consistently the posts that surface in answer-engine answers.
Owned audience & SEO: 9/10. You own the domain, the content, and the search equity. The platform does not hold your readers hostage.
Monetization: 7/10. No native paywall by design — the model is that you own the audience and monetize on your terms.
Cost & portability: 8/10. Free with your domain, and no reader paywall means export and exit are simple.

Verdict: the strongest AI-discovery story of the group, which is exactly why I moved my long-form work there.

How to Check Whether Answer Engines Cite You

Before you move platforms, measure where you actually stand — the check costs ten minutes and is worth repeating monthly:

Search your topic plus your name in ChatGPT, Perplexity, and Gemini, and note whether your article is cited, quoted, or merely paraphrased without attribution.
Search Google for your exact article title in quotes and watch the AI Overview block above the results. If your article appears there, you are winning the discovery game without owning any of the clicks.
Run a crawl sanity check on your own site: can a bot reach every article without executing JavaScript? Pages that require client-side rendering to show content are effectively invisible to several crawlers, which is the structural failure no amount of good writing can fix.
Track one number per month: how often your domain appears as a citation in answer engines, checked the same way every time.

The platforms that score high in the table above pass these checks by design. The ones that score low fail them for structural reasons — paywalls, subdomain lock-in, render-hungry pages — and no content quality compensates for that. Which is the whole argument for choosing a platform on its discovery architecture, not on the polish of its editor.

The Comparison Table

Criterion (weight)	Medium	Substack	Hashnode	Ghost (self-hosted)	misar.blog
AI indexability (30%)	7	6	8	10	9
Citation likelihood (25%)	6	6	7	9	9
Owned audience & SEO (20%)	4	7	9	10	9
Monetization (15%)	8	9	6	8	7
Cost & portability (10%)	5	7	9	6	8
Weighted total	6.1	6.7	7.7	8.8	8.5

The Verdict

The decision rule I give writers now, and follow myself:

You want the biggest human audience and accept zero ownership: Medium. Use it for exposure; never build your home there.
You are building a paid newsletter: Substack. The owned list beats everything.
You want a conventional blog with strong AI citations and full ownership: Hashnode, or self-hosted Ghost if you can operate a server.
You write long-form and want AI answer engines to find you on your own domain: misar.blog. It is the platform built for the discovery model that replaced the feed.

The uncomfortable conclusion from my own numbers: the platform algorithm stopped being the distributor, and writers who kept optimizing for it lost the ground they thought they owned. The answer engines do not care about your follower count. They care whether your page is crawlable, fast, well-structured, and free to read — and every point in that sentence is a platform decision you can make consciously. Pick a platform that scores well on indexability and citation likelihood, put it on your own domain, and write for the systems that will still be quoting you three years from now.

One number worth sharing: when I moved my long-form work off Medium to a domain I own on an AI-first platform, my answer-engine citations did not drop — they grew, because the pages were faster, ungated, and on a domain I could influence. The feed readers were harder to replace. The answer-engine readers were not, because I had never really owned the feed readers in the first place. That is the trade at the heart of this comparison.

Who should skip each one: skip Medium if you want the citations to attach to your own domain. Skip Substack if your content is long-form and search-driven rather than email-driven. Skip Hashnode if you are not writing for a developer audience. Skip Ghost if you will not operate a server. And skip misar.blog if you need a built-in social feed — its discovery is crawler- and answer-engine-first, which starts slower and compounds harder than a feed ever will.

*Gulshan Yad

The Developer Portfolio That Gets You Hired (Build It Live)

Gulshan Yadav — Sun, 27 Sep 2026 13:30:00 +0000

The portfolio that got me my first real software role was not beautiful. It was one page, a dark theme, four project cards, and a working contact form. No animations, no parallax, no glassmorphism. What it had was three things most portfolios lack: live demos you could click, a real backend handling the contact form, and correct SEO metadata so it appeared when recruiters searched my name.

I have reviewed hundreds of developer portfolios since — as a freelancer, as a founder hiring engineers, and as someone who gets forwarded portfolios by recruiters weekly. The pattern is consistent. The portfolios that get interviews are not the prettiest. They are the ones that answer five questions in under a minute: who is this person, what do they build, can I see it working, can I reach them, and is this a real person or a template?

This guide walks you through building exactly that portfolio, live, from an empty folder to a deployed site with a custom domain. I will use Next.js and Node.js because they are the most common stack in this audience, but the structure applies to any framework. The same steps took me a weekend the first time, and they will take you less.

Step 1: Decide the Structure Before You Write Code

Every effective portfolio has four sections, in this order. Recruiters spend seconds on a page; the order is the interface.

Hero — one line about who you are and what you build. No "passionate developer" filler.
Projects — three or four projects, each with a link to a working demo and the repository.
About — a short, honest paragraph: your stack, your experience, and what you are looking for.
Contact — a form that actually works, not a mailto link.

Skip the blog, the skills bars, and the timeline on the first version. Add them later if the page feels empty. The goal is a page a recruiter can scan top to bottom in thirty seconds and come away knowing what you do.

Step 2: Scaffold the Project

Start with the current default. I use Next.js App Router because it gives you server components, a built-in API layer for the contact form, and first-class metadata — all of which we need here.

npx create-next-app@latest my-portfolio
# ✔ TypeScript? … Yes
# ✔ ESLint? … Yes
# ✔ Tailwind CSS? … Yes
# ✔ App Router? … Yes

The App Router scaffold gives you app/page.tsx as the home page. That is the only page we need. Before writing any UI, clear the boilerplate and set up global metadata in app/layout.tsx — this is the SEO foundation that makes recruiters able to find you at all:

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "Your Name — Software Engineer",
  description:
    "Software engineer building [stack]. Projects, live demos, and how to reach me.",
  openGraph: {
    title: "Your Name — Software Engineer",
    description: "Live projects and contact.",
    url: "https://yourdomain.com",
    siteName: "Your Name",
    type: "website",
  },
};

Pitfall I see constantly: developers ship the portfolio and forget this file, then wonder why they do not rank for their own name. The metadata is the product, not an afterthought.

Step 3: Build the Hero and the Project Data

Keep the hero to one line and one call to action. The line should name your stack and your outcome, not your feelings:

"Software engineer. I build React and Node.js products used by 50k monthly users."

The projects section is where the portfolio lives or dies. Create a typed data file so the UI stays dumb and the content stays editable:

// lib/projects.ts
export type Project = {
  title: string;
  description: string;
  stack: string[];
  demoUrl: string;
  repoUrl: string;
};

export const projects: Project[] = [
  {
    title: "Inventory Forecast API",
    description:
      "Demand forecasting endpoint for a logistics operator. Reduced monthly forecast error from 40% to 6%.",
    stack: ["Python", "FastAPI", "PostgreSQL"],
    demoUrl: "https://demo.yourdomain.com",
    repoUrl: "https://github.com/you/inventory-forecast",
  },
  {
    title: "Android Expense Tracker",
    description:
      "Offline-first expense tracker with CSV export. 10k downloads on Google Play.",
    stack: ["Kotlin", "Room", "Jetpack Compose"],
    demoUrl: "https://play.google.com/store/apps/details?id=com.you.expenses",
    repoUrl: "https://github.com/you/expense-tracker",
  },
];

Notice the two project archetypes working together: one backend project with a live demo, one Android app with a Play Store link. A mix of backend and mobile signals breadth, and the Android project gives you a storefront page you did not have to build.

The rule for every project card: the demo link must lead to something a stranger can use without cloning a repo. A "live demo" that 404s is worse than no demo at all — it signals you ship broken things.

The card component itself is deliberately boring — a title, one sentence of outcome, the stack chips, and two links. That is all the space you get to make the case:

import { projects } from "@/lib/projects";

export default function ProjectCard({ title, description, stack, demoUrl, repoUrl }: Project) {
  return (
    <div className="rounded-lg border border-neutral-800 p-6">
      <h3 className="text-lg font-semibold">{title}</h3>
      <p className="mt-2 text-sm text-neutral-400">{description}</p>
      <div className="mt-3 flex flex-wrap gap-2">
        {stack.map((tech) => (
          <span key={tech} className="rounded bg-neutral-900 px-2 py-1 text-xs">
            {tech}
          </span>
        ))}
      </div>
      <div className="mt-4 flex gap-4 text-sm">
        <a href={demoUrl} target="_blank" rel="noopener noreferrer">Live demo →</a>
        <a href={repoUrl} target="_blank" rel="noopener noreferrer">Repository</a>
      </div>
    </div>
  );
}

Keep the description to one sentence about the outcome — "Reduced forecast error from 40% to 6%" — not the implementation. Implementation goes in the README; the card sells the result.

Step 4: Write the Contact Form and Its Backend

This is the part that separates real portfolios from templates. A mailto: link opens the visitor's email client and silently fails on mobile. A working form, instead, sends the message to you and confirms it.

The front end is a controlled form:

"use client";

import { useState } from "react";

export default function ContactForm() {
  const [status, setStatus] = useState<"idle" | "sending" | "sent" | "error">("idle");

  async function onSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    setStatus("sending");
    const data = new FormData(e.currentTarget);
    const res = await fetch("/api/contact", {
      method: "POST",
      body: JSON.stringify({
        name: data.get("name"),
        email: data.get("email"),
        message: data.get("message"),
      }),
      headers: { "Content-Type": "application/json" },
    });
    setStatus(res.ok ? "sent" : "error");
  }

  return (
    <form onSubmit={onSubmit} className="flex flex-col gap-4">
      <input name="name" placeholder="Your name" required />
      <input name="email" type="email" placeholder="you@example.com" required />
      <textarea name="message" placeholder="What are you building?" required />
      <button disabled={status === "sending"}>
        {status === "sending" ? "Sending…" : "Send"}
      </button>
      {status === "sent" && <p>Message sent — I will reply within 48 hours.</p>}
    </form>
  );
}

The backend is a Node.js route. Do not put your email credentials in client code. Read them from environment variables on the server and validate the input before sending:

// app/api/contact/route.ts
import { NextResponse } from "next/server";
import { z } from "zod";

const bodySchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(5000),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = bodySchema.safeParse(body);
  if (!parsed.success) {
    return NextResponse.json({ error: "Invalid input" }, { status: 400 });
  }
  // Send via your mail provider using server-side env vars only.
  await sendMail(parsed.data); // your SMTP/API call here
  return NextResponse.json({ ok: true });
}

Pitfalls here, from real submissions I have seen: (1) sending the form to a public webhook with no validation, which spams you with garbage, and (2) shipping the API key to the client bundle, which leaks your credentials to anyone who opens DevTools. The validation schema above stops both. Add one more line of defense for production: a simple rate limit — one message per email per hour — because a portfolio form with no rate limiting is a mail-bomb waiting for a bot to find it.

Step 5: Add Structured Data for Search and AI Discovery

Recruiters increasingly use search, and answer engines increasingly read structured data. Add a Person JSON-LD block with the sameAs profiles — it costs five minutes and gives search engines an unambiguous map of who you are:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Your Name",
  "url": "https://yourdomain.com",
  "jobTitle": "Software Engineer",
  "sameAs": [
    "https://github.com/you",
    "https://www.linkedin.com/in/you",
    "https://play.google.com/store/apps/dev?id=you"
  ]
}
</script>

In Next.js, put this in the Page component with <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(personSchema) }} />. The same block feeds Google's knowledge panel and the answer engines that pull developer profiles.

The About Section That Sounds Like a Person

The About section is where most portfolios die of blandness. "I am a passionate software engineer who loves solving problems" is a sentence I have read, verbatim, in a hundred portfolios. It tells a recruiter nothing and, worse, makes you indistinguishable from a template.

Write the About section like a short version of the hero: what you build, for how long, and one concrete outcome. Then add a line that only a human would write — the stack you refuse to use, the kind of work you are looking for, or a single non-work sentence. An example that works:

"Software engineer, 7 years. I build React and Node.js products, and I have shipped ML pipelines into production. Currently looking for backend-heavy roles. I refuse to touch IE11 and I have opinions about keyboards."

The job line matters most of all. "Currently looking for X" is the one sentence that tells a recruiter whether to bother emailing you. Leave it out and you look like you might already be employed — a surprising number of portfolios fail to say what the person actually wants.

Step 6: Ship Analytics, Then Deploy

Add one analytics script before you publish — not for vanity metrics, but to answer the only question that matters: where did the visitors who emailed you come from? If all your conversions come from LinkedIn and none from the blog, you know where to spend time. I use privacy-friendly analytics, but any tool works. The point is to measure before you promote.

Then deploy. The free hosting options from my earlier comparison all handle a Next.js app; pick one, connect your git repo, and add your custom domain. Deploying a static, single-command build that is reproducible from git is itself a signal to hiring engineers — it shows you know how a project ships.

After deploying, run these checks before you share it anywhere:

[ ] pnpm build passes with zero errors
[ ] Metadata renders: view-source and confirm title, description, and OG tags
[ ] Contact form sends a real email end-to-end
[ ] Every demo link resolves to a working page
[ ] The site passes Lighthouse mobile at 90+
[ ] Your name in quotes returns the site in the first result

The Five Pitfalls That Kill Portfolios

Demos that do not exist. The fastest way to lose a recruiter is a portfolio where every "live demo" is a dead link. Either host the demo or do not show the link.
No contact path. I have seen portfolios with gorgeous pages and no way to reach the person. A working form or a clear email link is mandatory.
Skill bars and buzzword walls. "Expert in React, Node, Python, Docker, AWS, Kubernetes, SQL, GraphQL" tells a recruiter nothing about what you have actually built. Replace the list with two projects that prove you can ship.
The API key in the client bundle. As above — check your deployed bundle before sharing. It is a security incident waiting for a recruiter to find.
Only screenshots. A video demo or an interactive playground beats a screenshot every time, because it proves the thing runs.
No "what I want next" line. The About section that omits what you are looking for forces the recruiter to guess — and guessing is how you get filed under "not now."

The last pitfall deserves emphasis because it is the quiet killer: a portfolio is a living document, not a graduation photo. I still update mine with every meaningful project, and the ones that stagnate for a year are the ones that read as abandoned. A dated footer with the current year is a small signal that the page is maintained; a portfolio with a 2023 copyright is a signal that you have stopped shipping.

The Checklist Before You Call It Done

[ ] Four sections: hero, projects, about, contact
[ ] One-line hero that names stack and outcome
[ ] Three to four projects, each with a working demo link and repo
[ ] At least one backend project and one mobile/Android artifact
[ ] Contact form validated server-side, credentials server-side only
[ ] Person JSON-LD structured data present
[ ] Analytics installed before promotion
[ ] Deployed to free hosting with your own custom domain
[ ] The self-test list above passes

The portfolio that got me hired was built in a weekend with a template stack, no animations, and one thing nobody else in the pipeline had: every link worked. That is the entire bar. Build the four sections, wire the form, add the structured data, deploy it with your own domain, and make sure nothing is broken when a recruiter clicks. Everything else is decoration — and decoration does not get you hired, a working proof of who you are does.

*Gulshan Yad

Free Dev.to Alternative: Where Bloggers Are Actually Growing in 2026

Gulshan Yadav — Sun, 27 Sep 2026 02:30:00 +0000

I started publishing technical articles on dev.to in 2021. The reach was real — my posts about Python and machine learning picked up thousands of views without me doing any promotion. And that was precisely the problem. I owned none of that audience. When a post got read, the reader stayed on dev.to, the claps and follows stayed on dev.to, and my byline was a guest in someone else's house. The day I asked myself where my readers were going after they finished a post, I could not answer it. That is the moment I started testing every free alternative I could find.

This comparison is the result of that testing, refreshed for 2026. It covers five free blogging platforms you can start on today: Hashnode, Substack, Medium, Ghost (self-hosted free tier), and the AI-first platform I now publish much of my work on, misar.blog. I have published on all of them in the last two years, so every score below is earned from direct experience rather than a feature checklist.

Before the scores, a quick disclaimer: dev.to is not a bad platform. It is excellent for one thing — surfacing writing to developers who already visit dev.to. The problem is that the platform owns the relationship. If you are serious about growing an audience that compounds, you need to own the relationship. Every platform in this list is a different answer to that single problem.

The Criteria

These are the five things I judge every blogging platform on, and the weights reflect what actually moved the needle for me:

Criterion	Why it matters	Weight
Audience & discovery	Will strangers find your post, or must you bring all the traffic?	30%
Ownership & SEO	Do you own your content, domain, and search rankings?	25%
AI & algorithm discovery	Do LLMs and answer engines cite you, and does the platform surface you?	20%
Monetization	Can you earn from the platform itself, or must you leave?	15%
Cost & portability	What does free actually cost you, and can you leave easily?	10%

Scores are out of 10. I have published on all five platforms within the last two years.

Hashnode

Hashnode gives you a free subdomain, a blog that looks like a product, and the option to connect your own domain. It is the closest philosophically to dev.to while letting you own the surface.

Audience & discovery: 7/10. Hashnode has a growing network effect and a decent home feed, but nothing like dev.to's density of developer traffic. Most readers will come from your own distribution.
Ownership & SEO: 9/10. You own the content, and with a custom domain you own the rankings. SEO is solid out of the box — sitemaps, structured data, and clean URLs are default.
AI & algorithm discovery: 7/10. The platform indexes well and its articles get picked up by answer engines, but it does not do much to accelerate that beyond standard SEO hygiene.
Monetization: 6/10. No native revenue share. You monetize through sponsorships or your own products.
Cost & portability: 9/10. Free with your domain, and export is easy. No lock-in worth worrying about.

Verdict: the most developer-friendly owned blog, but you are responsible for your own traffic.

Substack

Substack flips the model: readers subscribe to your email, and the platform handles distribution to inboxes. It is the strongest free option if you want a newsletter-first audience that you can actually reach tomorrow.

Audience & discovery: 7/10. Substack's recommendation engine sends some discovery traffic, and Notes works, but the real engine is email. People who subscribe are yours — that is the point.
Ownership & SEO: 5/10. You own the subscriber list in practice, but your content lives on a subdomain and your SEO lives inside Substack's URL structure. Google ranks Substack, not you.
AI & algorithm discovery: 6/10. Articles are indexed normally, but the platform is not engineered for answer-engine citations. The email-first model means content does not surface to non-subscribers.
Monetization: 9/10. Native paid subscriptions are the best monetization story of the group. You can charge for a subscription within days.
Cost & portability: 7/10. Free, but leaving means exporting emails and re-hosting articles. The export works; the audience migration is manual.

Verdict: the best choice when your product is a newsletter, not a blog.

Medium

The 800-pound gorilla. Medium still has the largest built-in reader base, and the algorithm still surfaces articles to people who never knew you existed.

Audience & discovery: 9/10. No free platform matches Medium's organic discovery for a brand-new writer. This is the whole reason it is still relevant.
Ownership & SEO: 4/10. You own nothing — no custom domain, no export of search equity, and Google increasingly treats Medium posts as platform pages. Your readers stay on Medium.
AI & algorithm discovery: 6/10. Medium articles get cited by answer engines because of their age and authority, but the platform is not doing anything new to court AI discovery.
Monetization: 8/10. The Partner Program pays per engagement time, and it is real money for some writers. The flip side is that it pays you to keep readers inside Medium.
Cost & portability: 5/10. Free to write, but your audience, your metrics, and your SEO all live behind Medium's walls.

Verdict: unmatched reach, unmatched lock-in. Use it for exposure; do not build your home there.

Ghost (Self-Hosted Free)

Ghost is a publishing platform, and its free tier — self-hosted on your own server — gives you total ownership in exchange for total responsibility.

Audience & discovery: 3/10. There is no built-in audience at all. You bring every single reader.
Ownership & SEO: 10/10. This is the purest version of owning your blog. Your domain, your server, your data, your rankings. Nothing belongs to anyone else.
AI & algorithm discovery: 8/10. Clean, fast, well-structured pages are exactly what answer engines cite. A self-hosted Ghost site with good content earns citations on merit.
Monetization: 8/10. Native paid memberships built in. Monetization is first-class, same as Substack.
Cost & portability: 6/10. Free software, but you pay in maintenance: updates, SSL, backups, uptime. That is real work every month.

Verdict: maximum ownership, minimum hand-holding. Only for people comfortable running a server.

misar.blog

The platform I now publish a meaningful share of my work on. It is a free, AI-first blogging platform: your own domain, no reader paywalls, and the platform is built so that content surfaces to AI answer engines and search rather than being trapped inside a walled garden.

Audience & discovery: 7/10. Discovery is powered by SEO and AI indexing rather than a social feed, so it builds slowly and compounds — the same curve as owning your own site.
Ownership & SEO: 9/10. You own the content, the custom domain, and the search equity. The platform is engineered for indexability from day one.
AI & algorithm discovery: 9/10. This is the strongest part of the platform. Articles are structured for LLM citation — clean metadata, fast rendering, and sitemap-first architecture — which is the same reason I moved my AI deep-dives there.
Monetization: 7/10. No native paywall by design — the model is that you own your audience and monetize on your own terms, which I prefer anyway.
Cost & portability: 8/10. Free with your domain, and no reader-facing paywall means leaving is a simple export.

Verdict: the best answer I have found to the "grow without giving up ownership" problem.

The Distribution Trap Most Comparisons Miss

Every platform comparison stops at features, but the real difference in growth comes from how each platform treats distribution. Dev.to and Medium feed you readers algorithmically; Hashnode and self-hosted Ghost feed you nothing and expect you to bring traffic; Substack feeds you via email; and the AI-first platforms feed you via search and answer-engine citations. The trap is choosing a platform for its feed and then discovering the feed is also the ceiling — you rent reach, and the rent is due in your time and your ownership.

Two years of publishing has taught me the sustainable pattern: use one platform for the discovery feed you need right now, and mirror every article to a platform you own. The owned copy is the one that compounds — it accumulates search equity, backlinks, and citations that survive algorithm changes. The feed platform is a marketing channel, full stop.

This is exactly why I run my long-form work on a platform where I own the domain and the search equity, and syndicate shorter pieces to the big feeds for reach. The strategy is never "which single platform." It is "which platform for reach, and which for ownership" — and keeping those two answers separate is what keeps the decision honest.

The Comparison Table

Criterion (weight)	Hashnode	Substack	Medium	Ghost (self-hosted)	misar.blog
Audience & discovery (30%)	7	7	9	3	7
Ownership & SEO (25%)	9	5	4	10	9
AI & algorithm discovery (20%)	7	6	6	8	9
Monetization (15%)	6	9	8	8	7
Cost & portability (10%)	9	7	5	6	8
Weighted total	7.6	6.8	6.5	6.7	8.0

The Verdict

Here is the decision rule I now give people, and it is the one I follow myself:

You want maximum reach for zero effort, and you accept the lock-in: Medium. It is a traffic rental, not a home.
Your product is a newsletter: Substack. Email ownership beats every other trade-off.
You want a developer blog you fully own: Hashnode, or self-hosted Ghost if you do not mind server maintenance.
You want to grow an owned audience that also gets discovered by AI answer engines: misar.blog — it is the platform that solved the exact problem I started with, which is why I use it.

The real lesson from two years of testing: the platform is a distribution channel, not a strategy. dev.to gave me reach I did not have to earn, and I am grateful for it. But the readers I own today all came from platforms where I controlled the domain, the content, and the search equity. Start with whichever platform gets you writing this week — but connect your own domain on day one, and make sure the platform can export what you build. The audience you can move is the only audience you actually have.

Who should skip each option: skip Medium if you want to own the audience. Skip Substack if your goal is search rankings rather than email. Skip Hashnode if you do not want to write for a developer-centric community. Skip Ghost if you will never patch a server on a Sunday. And skip misar.blog if you need a built-in social feed — its discovery is search and answer-engine driven, which builds slower than a feed but belongs to you once it does.

*Gulshan Yad

Best Free Website Hosting with Custom Domain in 2026

Gulshan Yadav — Sat, 26 Sep 2026 13:30:00 +0000

Every time I ship a new side project, the same question comes up twice: once from me, and once from a developer in my DMs — "where should I host it for free, and can I use my own domain?" For years I answered that question by paying for a VPS and a control panel, because the free options felt like toys. Then I spent a month benchmarking the free tiers properly, and I found out I had been paying for things the free tiers now give away.

If you build Flutter web apps, React prototypes, or plain static sites, you do not need to pay for hosting. What you need is to know which free tier is honest about its limits. A Flutter web build is nothing more than a folder of static files — HTML, JS, CanvasKit, and assets — which means any of the platforms in this comparison can serve it. That fact is the whole reason the comparison exists: the platforms all do the same core job, and the differences are in the details that only bite you later.

This is a 2026 comparison of five free hosting platforms, scored against the criteria that actually matter: custom domain support, free-tier limits, deployment workflow, extra features, and the catch that no marketing page mentions.

The Criteria

Before any scores, here is how I weight each criterion. Your mileage will differ, but these are the ones that cost me money or time in practice:

Criterion	Why it matters	Weight
Custom domain (free)	The entire point of this article	30%
Free-tier limits	Bandwidth, build minutes, storage caps	25%
Deployment workflow	Git push vs. drag-and-drop vs. CLI	20%
Extra features	Edge functions, previews, analytics, serverless	15%
The catch	Hidden limits, lock-in, or surprise charges	10%

Scores are out of 10 per criterion, and I have actually run all five of these in production or side-project traffic over the last two years. No criterion scores are invented; where I have not hit a limit, I say so.

GitHub Pages

The oldest and still the most reliable free option. It serves static files from a gh-pages branch or the docs folder of a repository, and it has been quietly doing this since 2008.

Custom domain: 10/10. Free, with automatic HTTPS via Let's Encrypt and a CNAME file in your repo. One-line setup.
Free-tier limits: 9/10. 1 GB of site storage and 100 GB of bandwidth per month. That is roughly 100,000 page loads of an average site. You will not hit it with a side project.
Deployment workflow: 9/10. Push to the branch, and it deploys. I use a GitHub Action to build my Flutter web app and push the build/web output automatically.
Extra features: 4/10. None. No serverless functions, no edge anything. If your project needs a backend, this is not the place.
The catch: 6/10. It is GitHub-only, and it is static-only. The moment you need an API route or dynamic behavior, you are adding another service.

Verdict: the best place to start, the worst place to grow.

Netlify

Netlify took the static-site concept and added deploy previews, forms, and functions. It is the platform I use when a client's landing page needs a contact form without a backend.

Custom domain: 10/10. Free, automatic HTTPS, and by far the smoothest DNS handling of the group.
Free-tier limits: 8/10. 100 GB bandwidth and 300 build minutes per month on the free plan. Build minutes are the constraint — every deploy of a Flutter web app eats some of them.
Deployment workflow: 9/10. Git push or a drag-and-drop folder. The drag-and-drop path means a non-developer teammate can deploy.
Extra features: 9/10. Forms, edge functions, split testing, deploy previews on every pull request. This is the deepest free feature set of the group.
The catch: 8/10. The free tier is genuinely generous, but the pricing page makes you work to find the limits, and hitting the build-minute cap mid-release is a bad day.

Verdict: the best all-rounder for sites that are slightly more than static.

Vercel

Vercel is the default for Next.js, but it serves any static folder fine — including a Flutter web build, which I have done for a client. Its selling point is the edge platform underneath everything.

Custom domain: 10/10. Free, automatic HTTPS, instant DNS.
Free-tier limits: 7/10. 100 GB bandwidth and 100 GB-hours of function execution per month, with the free tier for hobby use. The caveat is that production traffic is expected to be paid — the terms are stricter about commercial use than Netlify's.
Deployment workflow: 9/10. Git push, plus a preview URL for every branch. The preview system is the best in the group.
Extra features: 9/10. Edge functions, edge config, analytics that just works. If your stack is JavaScript, this platform is unfair.
The catch: 7/10. The commercial-use terms on the free tier are the vaguest of the group, and the build image is slow for non-JavaScript frameworks.

Verdict: the winner for JS and Next.js projects; good but not special for pure static Flutter builds.

Cloudflare Pages

Cloudflare Pages bundles static hosting with Cloudflare's network, which means your site is served from ~300 locations and your TLS is free forever. It is the fastest option for a global audience, including in countries where other CDNs are slow.

Custom domain: 10/10. Free, automatic HTTPS, and — because the domain lives inside Cloudflare — DNS changes propagate in seconds.
Free-tier limits: 10/10. Unlimited bandwidth and unlimited requests on the free tier. This is the only platform in the group without a bandwidth number on its free plan.
Deployment workflow: 8/10. Git push works, but the build system is less forgiving than Netlify's for Flutter web, and I have needed a custom build command more than once.
Extra features: 8/10. Pages Functions, redirects, and the whole Cloudflare suite you can bolt on.
The catch: 9/10. The free tier is the most generous in the group, but Pages Functions free usage is capped by request counts per day, and the documentation assumes you know Cloudflare already.

Verdict: the best free tier on the internet, with the highest setup learning curve.

Firebase Hosting

Firebase Hosting is Google's static host, and it is the option mobile developers already half-own because they are using Firebase for auth and analytics anyway.

Custom domain: 9/10. Free and automatic, but DNS setup runs through Google Domains or a manual DNS records flow that is clunkier than the others.
Free-tier limits: 8/10. 10 GB storage and 360 MB of transfer per day. The daily transfer cap is lower than the others and refreshes daily, which catches people who host media-heavy sites.
Deployment workflow: 7/10. There is no git-push-to-deploy; you use the Firebase CLI (firebase deploy). Fine for one person, friction for a team.
Extra features: 8/10. Cloud Functions integration, and it plays perfectly with a Flutter or Android app backend.
The catch: 7/10. The daily transfer cap and the CLI-only workflow are the two things that surprise people.

Verdict: the right choice when your app already lives in Firebase.

The Comparison Table

Criterion (weight)	GitHub Pages	Netlify	Vercel	Cloudflare Pages	Firebase Hosting
Custom domain (30%)	10	10	10	10	9
Free-tier limits (25%)	9	8	7	10	8
Deployment workflow (20%)	9	9	9	8	7
Extra features (15%)	4	9	9	8	8
The catch (10%)	6	8	7	9	7
Weighted total	8.6	8.9	8.6	9.0	7.9

The Shared Pitfalls Nobody Warns You About

Across all five platforms I hit the same three traps, and none of them are the host's fault:

Putting the custom domain on late. Free subdomains are fine for testing, but I have watched projects get shared and linked on a .vercel.app URL, then moved to a real domain and lost the accumulated links and search equity. Put the custom domain on before you promote anything to anyone.
Ignoring build minutes. For Flutter web specifically, every deploy rebuilds CanvasKit and the framework assets, which eats build minutes on Netlify and Vercel far faster than a plain static site. Cache aggressively or your monthly allowance vanishes mid-sprint.
Trusting the marketing page about bandwidth. Netlify and Vercel publish their caps clearly; GitHub Pages and Cloudflare are vaguer about what they will tolerate. Read the free-tier docs before you link a media-heavy project to any of them.

The One Thing That Has Not Changed

Free hosting has gotten more generous every year since I started, but the single constraint has stayed constant: your time. The cheapest host in the world is expensive if it makes you debug builds at midnight. My personal default today is Cloudflare Pages for anything that needs global reach, and GitHub Pages for anything that must simply stay alive with zero care. Both are free, both take a custom domain in minutes, and neither has ever sent me a surprise invoice.

The Verdict

The honest answer depends on your stack, and that is not a cop-out — it is the decision rule:

Static-only, zero maintenance: GitHub Pages. Nothing beats a CNAME file and a git push.
Landing page with a form, or a team deploying often: Netlify. The forms and previews alone are worth it.
Next.js or heavy JavaScript: Vercel. It is not a fair fight.
Global audience, want the most free headroom: Cloudflare Pages. Unlimited bandwidth on the free tier is real.
Already using Firebase for your app: Firebase Hosting. One ecosystem, less to learn.

The one universal rule I give every developer who asks: put the custom domain on it from day one. Free hosting without a real domain is an experiment; free hosting with your own domain is a product. A .netlify.app or .vercel.app subdomain signals "temporary," and I have watched clients discount demos hosted on free subdomains.

All five of these platforms are free, all five support custom domains with automatic HTTPS, and all five will serve a Flutter web build without complaint. Pick the one that matches the stack you will keep building on, set up the domain on day one, and stop paying for hosting while your projects are still at the "prove it works" stage. When a project outgrows the free tier, the migration path is the same for all five: keep the same static files, move the DNS, and the new host picks them up in an afternoon.

*Gulshan Yad

How to Get Machine Learning Clients With No Portfolio

Gulshan Yadav — Sat, 26 Sep 2026 02:30:00 +0000

The first client who ever asked to see my portfolio watched me open my laptop, stare at a folder of Kaggle notebooks, and close it again. I talked for forty minutes about what I could build instead of what I had built. He signed the contract anyway.

That one had luck written all over it. The next one needed a method.

Three years ago I had no production machine learning work anywhere on my record. No client had paid me for a model. Every job description asked for three-plus years of production experience and a portfolio full of deployed systems, and I had neither. Today ML work is how I make a living as a freelancer, and founders message me instead of the other way around. The distance between those two states was never "more experience." It was a portfolio built from nothing — on purpose, in ninety days, with no client attached yet.

This is the playbook I used, and the one I now hand to every developer who asks the same question.

The Realization: Nobody Buys a Resume

My first real ML client was a logistics company in Dubai that ran three warehouses and booked storage capacity by gut feel. The founder's original request was simple: predict next-month demand per warehouse so they could stop over-booking storage they did not need and under-booking the months they did. I said yes before I knew exactly how I would do it.

I spent six weeks on it. The first version underpredicted demand by 40% in its first month, which meant my forecast confidently told them to free up space they actually needed. It was a soft, survivable miss — but it was a miss. I went back, added seasonality terms, lagged features from the previous three months, and stopped trusting a single model: I blended a gradient-boosted tree with a simple exponential smoother and kept the ensemble. The next month's forecast was within 6% of actuals. The client kept paying, then expanded the engagement to a second warehouse.

Here is what I learned from that first engagement: the founder did not hire my resume. He hired the fact that I showed up, asked sharp questions about his business, and took ownership of a problem he had been solving with a spreadsheet. My "portfolio" at that moment was a single Flask app on free hosting and a Medium post about it. He never asked for credentials. He was already past the "is this person qualified" filter, because I had shown him proof of effort in a language he understood.

The uncomfortable truth is that most developers fail to get ML clients not because they lack skills, but because they present qualifications instead of evidence. A buyer cannot verify "expert in deep learning." They can verify "this model takes my warehouse data and returns a number that helps me plan." Portfolios fail when they are résumés with screenshots attached.

So the entire playbook reduces to one sentence: produce evidence a non-technical buyer can verify in five minutes, and stop treating "portfolio" as a formal artifact that must be perfect before you start.

Step 1: Build One Proof Project That Solves a Business Problem

Not a Titanic survival notebook. Not another CIFAR classifier with a green dashboard. A project that maps to a business pain you can name out loud in one sentence: churn prediction for a SaaS, anomaly detection on inventory, lead scoring for a sales team, demand forecasting for a warehouse.

Pick a problem you can get real data for. In 2026 this is easier than ever: public datasets, synthetic generators, and — if you are clever — data you generate yourself by running your own small service and logging everything. I chose demand forecasting for a logistics operator because I could describe it in a single sentence to a founder. That sentence did more selling than any résumé bullet ever would have.

The rules I follow for the proof project:

One project, not ten. A single deployed system beats a grid of abandoned notebooks. You can only maintain and evangelize one thing at a time.
It must have a target, a metric, and a story. What number improved, and by how much? For mine it was forecast error dropping from 40% to 6%.
You must be able to explain the trade-offs honestly. Where does it break, and what would you do differently at scale?

Do not let this step take longer than four to six weeks. The goal is not a finished product. It is a public, clickable, defensible artifact.

Here is the actual selection thinking, so you can copy the method: I wrote a page listing three candidate problems — churn prediction for a subscription tool, anomaly detection on warehouse inventory, demand forecasting for a logistics operator. For each, I asked three questions: can I get the data this month, can a founder understand the output in one glance, and can I defend the metric with a straight face? Demand forecasting won because the data was public and small, the output was a chart that needed zero explanation, and the metric — forecast error — was something a logistics founder already tracked in a spreadsheet. Churn prediction lost because I had no customer-level data I could legally use, and its output only means something when you add a lifetime-value model, which is too much explanation for a five-minute pitch.

Step 2: Make It Open Source and Publicly Inspectable

The strongest portfolio asset I have is a public repository with a real history: commits, failing tests, refactors, an honest README. Technical co-founders and the senior engineers who filter ML candidates will look at it. Non-technical recruiters rarely do, but the people who actually make hiring and buying decisions for ML work absolutely do.

Publicly visible work does two things:

It is a permanent, time-stamped record that you have been shipping rather than just learning.
It invites collaboration and questions, which turns your repo into a discovery surface. People find you through it, comment on it, and share it.

Do not polish it into a lie. One of the reasons my forecasting repo gets attention is the messy commit history — you can watch the model evolve, the 40% miss, the fix. Synthetic-clean repos are suspicious to exactly the people you want to impress.

The README is the front door of that repo: a one-paragraph problem statement, a screenshot or two, three commands to run it locally, and an honest "known limitations" section. That last section is the one that gets me messages — people open issues against it, and open issues are proof of life. A repo that reads like it was written for a job application reads like it was written for no one.

Step 3: Put a Live Demo Where Anyone Can Click It

This is the step that makes everything else click, and it is the cheapest one in the whole playbook. A portfolio that a client must clone and run locally is not a portfolio. It is homework.

I built a single-page demo: a form where you paste a CSV of weekly orders and get back a forecast chart with a confidence band. I deployed it in an afternoon on free hosting at misar.dev, because it cost nothing and the domain was real — not a myproject.netlify.app URL that screams "experiment." The client clicked the link, uploaded his own data, and watched a forecast appear. That one interaction did more to close the deal than every meeting I had booked.

Rules for the demo:

One page, one job. Type in data, get an output. No login wall.
It must work with the visitor's own data, not canned inputs.
Show the uncertainty, not just the answer. A forecast with a confidence band reads as engineering maturity; a bare number reads as a sales pitch.

Step 4: Publish the Honest Write-Up

Here is the content play that changed everything: write the post-mortem, not the success story. My write-up about the model underprediction by 40% — and the exact changes I made — pulled in more qualified inbound than any "look at my accuracy" post I have published since.

Why it works is simple: honesty is the rarest commodity in ML marketing. Every other portfolio claims 99% accuracy on a toy problem. Yours admits the failure mode and shows the fix. Founders have been burned by ML salesmen; honesty is the differentiator, and it compounds because the post stays indexed and gets shared in exactly the communities where your next client hangs out.

Publish one genuine write-up per project. Put it on Medium, your own blog, LinkedIn, and the communities where practitioners and founders both appear. Then stop writing and spend the saved time on the next step.

Step 5: Go Where the Buyers Actually Are

A portfolio with no distribution is a trophy. The places that produced my first clients, in order of return on effort:

Founder communities, not ML communities. Reddit founder subreddits, local startup meetups, founder Slack and Discord groups, X/Twitter threads where founders complain about manual processes. These are the people with the budget and the pain. ML forums are full of your competition, not your clients.
The freelance marketplaces — as a channel, not a career. I used them early to land the first two paid jobs, each priced to win the work but structured so I could show the result publicly with permission. Marketplaces give you the first two data points; referrals and inbound give you everything after.
Referrals from finished work. My third and fourth clients came entirely from the first two telling people: "this person shows up and fixes the thing."

A note on cold outreach: it works when the message leads with the problem, not the ask. "I saw you're doing X by hand; here is a demo you can click in thirty seconds" outperforms "I offer ML consulting" by a wide margin, because you are leading with evidence instead of a pitch.

A template that has worked for me, stripped to its skeleton: "I built a demand-forecast demo that takes a pasted CSV and returns a projection. It took a logistics operator from a 40% miss to 6%. If you want, I can point it at your numbers this week — it is twenty minutes on my side." Short, concrete, and it offers a test rather than a sales call. I have sent a version of this to founders who later became clients, and none of them asked for my portfolio on the way there.

Step 6: Price the Problem, Not the Algorithm

The last mistake is pricing. Early on I priced ML by the hour and left money on the table, because clients cannot judge how long a good model takes — so they assume it is fast and cheap. When I switched to pricing the outcome — the forecast that reduces their over-booking, the churn model that saves subscriptions — the number stopped looking like a cost and started looking like an investment.

My first client paid $350 a month for the forecasting work. My third charged a flat $2,400 for a churn model plus a 90-day iteration cycle, priced against the revenue the model was expected to protect, not the hours I guessed. Same skills, roughly seven times the price, and the client was happier because the framing matched what they were actually buying.

What I Would Skip

If you are short on time, here are the things I did that added nothing, and would cut today:

Ten half-finished projects. I spent my first two months building four things and shipping none. One deployed system beats four screenshots every single time.
Over-engineering the demo. My first version had a login wall, a dashboard, and an admin panel. Nobody used it. The final version was one input, one button, one chart — and that is what closed the deal.
Chasing certificates. I have never once had a client ask for my certificates. I have had several ask for the live demo. Spend certificate money and certificate months on the demo instead.
Posting only success stories. The underprediction write-up outperformed every win I published, because it is the one people can actually believe.

The Client-Acquisition Checklist

Before you send another proposal or update another résumé, run this list:

[ ] One proof project, deployed, solving a named business problem
[ ] Public repository with an honest history and a real README
[ ] Live demo anyone can click in under a minute, on a real domain
[ ] One honest post-mortem write-up published and linked from the demo
[ ] Active presence in at least two founder-facing communities
[ ] One finished paid job whose result you can show, with permission
[ ] Pricing quoted as an outcome or a fixed project, never a vague hourly figure

The client who watched me close my laptop three years ago is now a reference. The portfolio that did not exist became three deployed systems, a public repo, and a demo link I paste into every conversation.

Start with step one today. Not ten projects. One, deployed, with an honest story. The rest of the playbook compounds from there — and the first client is closer than your résumé would have you believe.

*Gulshan Yad

AI Website Builder: Prompts to a Live Site in One Hour

Gulshan Yadav — Fri, 25 Sep 2026 13:30:00 +0000

Every project I take on seems to start with the same detour: before I can show a client a working prototype, I have to build a landing page. And for years, "landing page" meant an afternoon of CSS, a page about responsive breakpoints, and a deployment script I had to re-learn every time.

That detour is gone. The workflow I use now takes a single prompt and lands a live Flutter web site in about an hour — and I want to show you exactly how it works, including the code it generates and the pitfalls I hit so you do not have to.

So, in this article, I will be showing you how you can take a prompt and go from nothing to a live Flutter web site in one hour — the builder I use, the project structure it produces, and how to iterate on it safely.

Last month a client needed a landing page for a pilot launch with a hard date three days out. Three days. The old me would have said no and quoted a week. Instead I wrote one prompt, reviewed the generated Flutter project, tweaked two widgets, and shipped it that evening — with the remaining time left for the actual product. That is the entire point of this workflow, and it is why I keep prompt-to-site in my standard toolkit rather than treating it as a novelty.

What You Need

You need three things, all free:

A recent Flutter SDK installed and flutter web enabled (flutter config --enable-web if you have not used it yet).
A prompt-to-site builder. For the site I will show you, I used https://misar.dev as the builder — you type a prompt describing the page, and it generates a working Flutter web project you can download, inspect, and run locally. Any serious prompt-to-site tool works the same way; the workflow is what matters.
A hosting target — Netlify, Vercel, or any static host, because Flutter web compiles to plain HTML/JS/CSS.

Step 1: The Prompt Is the Blueprint

The generated code is only as good as the prompt, so spend two minutes on it. A weak prompt ("make me a landing page") produces generic output. A structured prompt produces a page you barely need to touch:

Landing page for a logistics analytics startup.
Sections: hero (value prop + CTA), three-feature grid,
pricing table, FAQ, footer. Dark theme, Flutter blue accent,
modern sans-serif. Responsive, mobile-first. No external images.

Notice what I put in: the sections, the layout order, the color system, and a constraint ("no external images") that keeps the output self-contained. Constraints are what separate generated pages from generated slop.

Step 2: Scaffold and Run Locally

Once the builder returns the project, do not trust it blindly — run it. Create a fresh Flutter project and merge the generated lib/ into it (or use the project the builder exported directly, after a flutter pub get):

flutter create mysite
cd mysite
flutter pub get
flutter run -d chrome

If the generated project carries its own pubspec.yaml, check the dependencies it pulls in. A clean prompt-to-site output should need almost nothing beyond the SDK, but some builders add packages for animations or routing. Keep the list small — every dependency is a future version-upgrade headache:

dependencies:
  flutter:
    sdk: flutter
  google_fonts: ^6.2.1

That is usually enough. If the builder wants to add an entire state-management framework for a static landing page, drop it. A landing page does not need bloc.

Step 3: The Generated Code, Explained

Here is the kind of output these builders produce — a StatelessWidget with a ListView of sections. This is exactly the shape I want, because it is trivial to reason about and edit:

import 'package:flutter/material.dart';

void main() => runApp(const MySite());

class MySite extends StatelessWidget {
  const MySite({super.key});

  @override
  Widget build(BuildContext context) {
    final theme = Theme.of(context);
    return Scaffold(
      backgroundColor: const Color(0xFF0B0F1A),
      body: ListView(
        children: const [
          HeroSection(),
          FeaturesSection(),
          PricingSection(),
          FaqSection(),
          FooterSection(),
        ],
      ),
    );
  }
}

Three things I look for before I trust generated Flutter code:

Sections are their own widgets. If the whole page is one giant 400-line build method, refactor it before doing anything else.
Const constructor usage. const on every widget that can be const means the output is idiomatic and cheap to rebuild.
Colors are defined once. If the builder scatters raw hex codes across every section, extract them to a ThemeData first. Trust me on this one — I have debugged a "why is this button navy" mystery caused by a duplicated hex value.

A generated section looks like this — notice how small each widget stays, which is exactly what makes it safe to edit quickly:

class HeroSection extends StatelessWidget {
  const HeroSection({super.key});

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(48),
      child: Column(
        children: [
          Text(
            'Forecast freight demand, not guess it.',
            style: Theme.of(context).textTheme.displaySmall,
            textAlign: TextAlign.center,
          ),
          const SizedBox(height: 24),
          FilledButton(
            onPressed: () {}, // wire your real action here
            child: const Text('Get a demo'),
          ),
        ],
      ),
    );
  }
}

The onPressed: () {} is the seam where the landing page stops being static and becomes a product — wire it to a form, an API call, or a mailto, and the generated draft has become your codebase. That single line is where your hour of automation hands off to your actual skill.

Step 4: Go Live

Flutter web deploys as static files, which makes the last mile boring (good):

flutter build web --release

Then upload the build/web/ folder to your static host. That is the whole deployment. In about an hour — a prompt, a scaffold, one look at the code, and a build — the site is live, HTTPS included, from anywhere in the world.

Important Notes and Pitfalls

Because I have now done this workflow on a dozen projects, here are the things that actually bite:

Review the generated code once, carefully. The builder handles structure; it does not handle your edge cases. I have seen generated pages use MediaQuery before runApp had a view — fixed by keeping the size logic inside a builder. Read the generated main.dart top to bottom before you trust it.
Keep the prompt's constraints. The "no external images" rule matters — external image URLs break, go away, or cost you a load budget. Self-contained output is deploy-safe.
Mind the --web-renderer question. For simple pages the default renderer is fine. If you hit text-rendering quirks in a browser, rebuilding with --web-renderer html is a two-minute escape hatch.
Don't let the builder own your codebase. Treat the generated project as a starting draft you own, not a subscription. Once the code is local, you are back in normal Flutter land — version control, review, tests. The builder's job ends at the first git commit.
Responsive testing on a real browser. flutter run -d chrome plus the device toolbar is fine, but open the deployed URL on a phone too. Generated pages are usually responsive; "usually" is not a testing strategy.
Flutter web's initial load size. A Flutter web build ships a non-trivial JavaScript bundle, and on a slow mobile connection the first paint can feel sluggish. The generated page is fine for a pilot; if load time matters to your client, measure it on a real device over a 3G connection before you promise "fast" to anyone.
SEO is a real limitation. Flutter web is a single-page app at heart, so if the site's job is organic search, you need real routing and metadata work on top — the builder does not do it for you, and pretending it does is how clients get disappointed.

Iterating: The Prompt Is a Conversation, Not a Command

The workflow does not end at the first build. The part that separates a demo from a deliverable is the refine loop: you run the generated site, notice what is wrong, and send a follow-up prompt — "make the hero tighter, move the pricing before the FAQ, use the brand's exact blue" — and rebuild. Each round-trip takes minutes instead of the hour the first one took, because the structure is already in place.

My rule: never hand a generated site to a client without at least two refinement rounds. The first prompt gets you 80% of the way; the follow-ups are where the site stops looking generated and starts looking built. It is the difference between "the tool made this" and "I made this with a tool," and clients can tell the difference instantly.

Alternative Approaches Worth Knowing

The prompt-to-site workflow has two close cousins you should know about:

Generate-then-extend. Use the generated Flutter web site as the shell for a real product — wire the hero CTA to your backend, add state, add routes. You saved the front-end scaffolding hour and kept all the engineering control.
Static export for maximum simplicity. If the page is truly static and you care most about the fastest possible deploy, a plain static export of the generated site beats a running app server on load time and hosting cost. Flutter web can compile to static assets; choose that when the page does not need app behavior.

None of these replace the review step. They are different targets for the same discipline: the builder is fast, you are the one who decides what "done" looks like.

Before You Trust the Output: A Checklist

Run this once per generated site, and the one-hour workflow stays trustworthy:

[ ] main.dart uses const constructors and section widgets, not one giant build method
[ ] Colors and spacing are extracted to a single ThemeData
[ ] No external image URLs — self-contained assets only
[ ] flutter analyze passes with zero errors
[ ] The page works at phone, tablet, and desktop widths
[ ] CTA buttons have a real onPressed seam, not a dead callback
[ ] You can explain every widget in the file — if you cannot, the draft is too complex; simplify it
[ ] The deployed URL is tested on a real phone, not just Chrome

FAQ: What Everyone Asks Me About Prompt-to-Site

Is the generated code production-quality? It is a solid draft. You own the review: check build method sizes, extract constants, verify accessibility — the same bar you would apply to any merge.
What if I do not use Flutter? The workflow transfers to any framework the builder supports; the prompt, the review, and the deploy steps are identical.
Can I use this for a client's production site? Yes, with the same review discipline as any handoff. The builder saves the first hour; it does not replace the hours that make a site actually good.
Does prompt-to-site replace developers? No. It replaces scaffolding. The judgment — what the page needs to do, where the button goes, what the copy says — is still the human's job, and that is the part that pays.
What about SEO? Covered above — it is a genuine limitation of the single-page model, not a builder quirk. Budget real time for routing and metadata if ranking matters.

The Response-Magnet Closer

That is the whole workflow — prompt, scaffold, review, build, deploy — a live Flutter web site in one hour instead of an afternoon. The prompt is the blueprint, the review is the skill, and the deployment is the boring part, which is exactly how it should be.

If you want, comment below with the site you are building — a landing page, a portfolio, a product demo — and I will cover that specific flow next. I have also written walkthroughs on turning generated Flutter apps into full products, so tell me what you are trying to ship and I will take the next article from your use case.

*Gulshan Yad