DEV Community: Ritika Rajput

Making My Portfolio Less Boring: 4 Small Redesigns That Made a Big Difference

Ritika Rajput — Tue, 03 Nov 2026 06:14:24 +0000

When I first launched my portfolio, it worked, but it felt empty. Some pages had big text and lots of blank space. Some sections said "Coming soon". Two pages almost looked the same.

I didn't rebuild anything. I made four small changes, and the site felt much more finished. Here they are, with examples you can copy.

1. Replace "Coming soon" with real work

My Projects page ended with two cards that said "Coming soon" and "A new piece is finding its final frame." They looked unfinished, and they told visitors there was nothing there.

I deleted them and used real things I had already built instead:

A side project (a Python script that publishes a blog post every day with GitHub Actions)
My articles on dev.to

Placeholder cards don't help anyone. If you have nothing new to show, remove the section. If you have something real, even a small project or an article, show that.

<a
  href="https://github.com/your-username/your-repo"
  target="_blank"
  rel="noopener noreferrer"
  className="flex flex-col gap-3 rounded-2xl border border-[var(--border)] bg-[var(--surface)] p-5 transition-colors hover:border-[var(--accent)]"
>
  <span className="text-xs uppercase tracking-wider text-[var(--text-muted)]">Project</span>
  <h3 className="text-lg font-semibold">Daily blog automation</h3>
  <p className="text-sm leading-6 text-[var(--text-muted)]">
    A Python script that writes and publishes a blog post every day.
  </p>
  <span className="mt-auto text-sm font-semibold text-[var(--accent)]">View on GitHub →</span>
</a>

2. Use the empty space next to a big heading

My Contact page had a huge heading on one side and nothing on the other. A visitor had to scroll to find out how to reach me.

I moved the contact options next to the heading as three clickable cards: Email, WhatsApp and LinkedIn. Under the heading, I added small chips for what I can help with.

<div className="grid gap-8 lg:grid-cols-2 lg:items-center">
  <div>
    <h1>Let's make something good.</h1>
    <p>Have a project in mind? I'd love to hear what you're thinking.</p>
  </div>
  <div className="flex flex-col gap-3">
    {/* three contact cards here */}
  </div>
</div>

The same idea worked on my Skills page: the empty right side now shows four small cards that link to the skill details below.

3. Turn a row of small links into cards

My "Find me online" section was a row of tiny text chips. They were easy to miss, and a visitor couldn't tell what each link was.

I changed them into larger cards with an icon, a name and one short line, such as "Articles on web development and automation". Now each link explains itself before anyone clicks it.

Keep each card focused on one job: an icon, a title, one line of description and one clear action.

4. Check your contrast

My "Let's Work Together" banner had white text on a light lavender background. On my laptop it looked fine, but it was hard to read on a phone, and the button text was also light.

The fix was simple:

Use a deeper purple for the banner background
Use white text on it
Make the button text the same deep purple on a white button

If you can barely read something when you squint, a visitor with a small screen and bright sunlight will not read it at all.

A bonus: make every page do a different job

My Home and About pages used the same hero, the same photo and the same story. I changed them:

Home: a short hero, a few skills and clear buttons
About: the full story, what I'm currently learning, and my profiles

When two pages say the same thing, a visitor sees no reason to open the second one. It can also confuse search engines.

My rules for every change

Use only real content. No invented numbers, clients or promises.
One change at a time. Then I look at the page on a phone-sized window and a laptop.
Remove before adding. Often the best fix was to delete something.
Check on a real phone. Some problems only show up there.

Wrapping up

None of these changes needed a new framework or a big rewrite. They only needed me to look at my own site the way a visitor does.

You can see the result here: ritika-rajput-portfolio.vercel.app. I also share videos on RitikaMoments.

What is one thing on your portfolio that you know looks unfinished?

What I Learned Using Free AI Coding Agents on a Real Portfolio (OpenCode and Kilo)

Ritika Rajput — Mon, 02 Nov 2026 06:25:33 +0000

I'm a student, and I built and kept improving my portfolio with free AI coding agents running in the VS Code terminal. I used OpenCode and later Kilo, both on free models.

They saved me a lot of time, but they also got stuck, lied by accident, and once looked busy for a whole hour without doing anything. Here is what I learned, so you can skip my mistakes.

1. Ask for a read-only diagnosis first

My mobile menu showed a dark overlay and an "X" button, but the menu links never appeared. My first prompt was "fix it", and the fix didn't work.

What worked was splitting the job into two steps:

First, read only. Do not change anything.
Find where the mobile menu is rendered and tell me exactly why the panel
is invisible, with the file and line number.
Then fix it.

When the agent has to name the real cause, it stops guessing. In my case the real cause was a previous commit that had removed the menu panel completely.

2. Keep every prompt small

My long prompts that asked for five changes at once often ended with "not done in this session". Short prompts with one job each worked much better.

A prompt template I now use:

Change ONLY <one function or one section> in <one file>.
Do not touch anything else.
Use only text that already exists. Do not invent new content.
Do not commit or push.
Run the typecheck at the end and tell me which lines you changed.

3. Always tell the agent not to commit or push

Agents are happy to "help" by committing and pushing. I wanted to review every change first. So every prompt says: do not commit or push. I check git status and git diff myself, and then I commit.

4. Typecheck passing does not mean the build passes

Several times the agent said "typecheck passed", and I still had problems after deploying. The typecheck only checks types. A real build can still fail, and a failed build on Vercel means your site stays on the old version.

Ask for the build too, and when it uses environment variables, give them:

$env:PORT="5180"; $env:BASE_PATH="/"; pnpm --filter @workspace/ritika-portfolio build

Before you ask "why is my change not live?", check the deployment status in the Vercel dashboard.

5. Don't let the agent test in a browser

I once asked an agent to verify a fix with a headless browser. It spent an hour fighting spawn pnpm ENOENT on Windows and trying one workaround after another. Now my prompts say: "Do not test in a browser or start a dev server. Only run typecheck and build." I look at the page myself.

6. Watch out for Windows and PowerShell

Agents often write bash commands. On Windows PowerShell I kept seeing errors like:

&& is not a valid statement separator (use ; instead)
grep, tail and head are not recognized commands
2>/dev/null fails with a path error

If your agent keeps hitting these, add a line like "I use Windows PowerShell, so use PowerShell syntax" to your prompt.

7. "Already implemented" needs checking

A few times the agent answered "Already implemented, no changes needed". Sometimes that was true. Sometimes I wanted proof. I started asking it to name the file and line number of the change, and then I searched for that text in VS Code with Ctrl + F. If the agent can't point to a line, don't trust the claim.

8. Free models have limits

Free agents can hit a daily limit, or ask you to sign in. Mine said "You need to sign in to use this model" in the middle of a task. Signing up with an email was free and took a couple of minutes. Be ready to switch tools, and never run two agents on the same folder at the same time, because they will edit the same files and cause conflicts.

9. Never paste secrets to an agent

Don't paste API keys, tokens or your .env file into a prompt or a chat. Keep them in environment variables and in your host's secret settings. Before pushing, search the diff for words like key, secret, token and password.

My simple workflow now

Ask for a read-only diagnosis
Ask for one small change
Run git status and git diff --stat
Run the build locally
Test the page myself, on desktop and on a phone-sized window
Commit with a clear message and push
Check that the deployment is Ready
Check the live site in an incognito tab

Wrapping up

AI agents are great helpers, but they are not a replacement for checking your own work. The more specific and small my prompts were, the better the results.

You can see the portfolio I built here: ritika-rajput-portfolio.vercel.app. I also share videos on RitikaMoments.

What is the biggest problem you ran into while coding with an AI agent?

Helping Google Know Who I Am: SEO for a Developer Portfolio (Person Schema, Canonical Tags, sameAs)

Ritika Rajput — Sat, 31 Oct 2026 06:48:36 +0000

My name is a common one. When I search it, results are mixed, and my own portfolio is not guaranteed to show up. So I spent some time making my portfolio easier for Google to understand.

I can't promise this will rank me first, because Google decides that. But these changes give search engines clear signals about who I am. Here is what I did on a React portfolio hosted on Vercel.

1. Each page needs its own canonical tag

My first problem was in Search Console. One page showed "Alternate page with proper canonical tag" and was not indexed.

URL Inspection showed the canonical was my home page (/), not the page itself. A single hard-coded <link rel="canonical"> in index.html was shared by every route, so Google treated my other pages as duplicates of the home page.

The fix: set the canonical per route.

import { useEffect } from "react";

const SITE = "https://your-domain.com";

export function useCanonical(path: string) {
  useEffect(() => {
    let link = document.querySelector<HTMLLinkElement>('link[rel="canonical"]');
    if (!link) {
      link = document.createElement("link");
      link.rel = "canonical";
      document.head.appendChild(link);
    }
    link.href = `${SITE}${path}`;
  }, [path]);
}

2. Unique titles and descriptions per route

I gave every page its own title in a consistent pattern, with my name first:

Home      | Your Name | Web Developer & UI Designer from Your City
About     | About | Your Name
Projects  | Projects | Your Name
Blog      | Blog | Your Name
Contact   | Contact | Your Name

Each page also has its own meta description. For a single-page app, I update document.title and the meta tags when the route changes.

A tip: don't stuff keywords. Write titles and descriptions that a real person would want to click.

3. Add Person structured data (JSON-LD)

Structured data tells Google exactly what your site is about. For a personal site, the Person type is a good fit.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Your Name",
  "url": "https://your-domain.com/",
  "image": "https://your-domain.com/your-photo.jpg",
  "jobTitle": "Web Developer & UI Designer",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Your City",
    "addressRegion": "Your State",
    "addressCountry": "Your Country"
  },
  "knowsAbout": ["Web development", "React", "TypeScript", "UI design"],
  "sameAs": [
    "https://www.youtube.com/@your-channel",
    "https://www.linkedin.com/in/your-profile",
    "https://dev.to/your-username",
    "https://github.com/your-username",
    "https://your-blog.blogspot.com"
  ]
}
</script>

Two things to be careful about:

Keep only one Person block, and don't repeat keys like image or sameAs. A duplicate or a typo can break the JSON.
Only add profile links that are really yours. I once nearly added a GitHub URL that was a guess, and it could have pointed to a stranger's profile. Always open every sameAs link and confirm it is your account.

After deploying, check it with the Schema Markup Validator at validator.schema.org.

4. Link your profiles to each other

sameAs works best when the links go both ways:

Put your portfolio URL in your GitHub, LinkedIn, dev.to and YouTube profiles
Link to your YouTube, LinkedIn, GitHub and blog from the portfolio
Use the same name everywhere

This helps search engines connect all of these accounts to one person.

5. Make the content itself clear

One h1 per page that matches the page's purpose
Descriptive alt text on your profile photo, with your name
A sitemap with every route, using your real domain
Real text content on each page, not only images and cards
Don't make two pages show the same content. I noticed my Home and About pages were nearly identical, and fixed it by giving each a different purpose

6. Tell Google about the changes

Deploy to Vercel
In Search Console, paste the URL into URL Inspection
Click Test live URL, then Request indexing
Submit sitemap.xml under Sitemaps

Indexing can take days to weeks, and requesting it again and again doesn't speed it up.

What I'm watching now

I don't have ranking results to show, and I won't pretend I do. What I'm tracking:

Whether the "not indexed" pages move to Indexed in Search Console
Whether my name plus "web developer" brings up my portfolio
Whether my GitHub, YouTube and dev.to profiles show up together

Quick checklist

[ ] A different canonical tag on every route
[ ] Unique title and description per page
[ ] One valid Person JSON-LD block with real sameAs links
[ ] Profiles link back to the portfolio
[ ] Sitemap submitted
[ ] No duplicate pages

Wrapping up

None of this is magic. It is about removing confusion for search engines and keeping your online presence consistent.

You can see the portfolio here: ritika-rajput-portfolio.vercel.app. I also share videos on RitikaMoments and write on dev.to.

Have you tried improving your own search presence? What worked for you?

How I Use Supabase as a Simple CMS for My Portfolio Blog

Ritika Rajput — Fri, 30 Oct 2026 08:02:49 +0000

When I added a blog to my portfolio, I did not want to edit code and redeploy the site every time I published a post. A small Supabase database solved this for me. In this post I'll show a simple setup you can copy: a table for posts, a storage bucket for images, and a few lines of code to read them.

1. Create a posts table

In the Supabase SQL editor, create a table with the fields a blog card needs:

create table posts (
  id uuid primary key default gen_random_uuid(),
  created_at timestamptz default now(),
  title text not null,
  excerpt text,
  content text,
  date date,
  slug text unique,
  cover_image text
);

The slug is used for the post URL, for example /blog/my-first-post. Making it unique makes sure two posts never share one address.

2. Add a storage bucket for cover images

Open Storage, create a bucket (I named mine site-images) and make it public. Upload an image and copy its public URL. It looks like this:

https://YOUR-PROJECT.supabase.co/storage/v1/object/public/site-images/my-cover.webp

Paste that link into the cover_image column of your post. A tip: compress cover images (WebP at around 1200 x 630 works well) so your blog cards load quickly.

3. Read the posts in your frontend

Install the client and create it with your project URL and anon key:

npm install @supabase/supabase-js

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://YOUR-PROJECT.supabase.co', 'YOUR-ANON-KEY')

To show the list of blog cards:

const { data: posts, error } = await supabase
  .from('posts')
  .select('title, excerpt, slug, date, cover_image')
  .order('date', { ascending: false })

To load one post on its own page, filter by slug:

const { data: post, error } = await supabase
  .from('posts')
  .select('*')
  .eq('slug', slug)
  .single()

If you write content in Markdown, render it with a library such as react-markdown or marked.

4. Keep it secure with Row Level Security

By default you do not want visitors to change your data. Turn on Row Level Security and allow only reading:

alter table posts enable row level security;

create policy "Public can read posts"
on posts for select
using (true);

With no insert, update or delete policy, visitors can only read. The anon key is meant to be used in the browser, but never put your service_role key in frontend code.

5. Publishing a new post

To publish, I open the Table Editor, insert a new row, paste the title, excerpt, slug and content, and add the cover image link. The post shows up on the site without any code change or redeploy.

Pros and cons

Simple and free to start, and no redeploy for new posts.
You control your data and can export it any time.
The Table Editor is not a writing tool, so long posts feel a bit clumsy. If you publish often, you can later build a small admin page on top of the same table.

Final thoughts

For a personal portfolio, a table, a bucket and a few queries are enough to get a working blog. You can see this kind of setup on the blog section of my portfolio, and you can find more about my work on the Skills page. If you try this, let me know in the comments how it went.

I Automated My Daily Blog with GitHub Actions, Gemini and the Blogger API

Ritika Rajput — Wed, 28 Oct 2026 07:21:15 +0000

I wanted my blog to publish a new post every morning without me touching it. So I built a small pipeline: GitHub Actions runs a Python script on a schedule, Gemini writes the post, and the Blogger API publishes it.

It worked, but only after I hit three errors that the tutorials never mention. Here is the setup and the fixes.

The architecture

GitHub Actions triggers the workflow every day on a cron schedule.
generate_post.py asks the Gemini API to write one post about a topic from a skills.txt list.
post_to_blogger.py publishes it through the Blogger API.
The workflow commits the saved post file so topics don't repeat.

All credentials live in GitHub Secrets, never in the code:

BLOGGER_CLIENT_ID
BLOGGER_CLIENT_SECRET
BLOGGER_REFRESH_TOKEN
BLOGGER_BLOG_ID
GEMINI_API_KEY

The workflow

name: Daily Blogger Auto-Post

on:
  schedule:
    - cron: "30 4 * * *"   # 10:00 AM IST (cron runs in UTC)
  workflow_dispatch:

permissions:
  contents: write

jobs:
  post:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - name: Generate post
        run: python scripts/generate_post.py
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
      - name: Post to Blogger
        run: python scripts/post_to_blogger.py
        env:
          BLOGGER_CLIENT_ID: ${{ secrets.BLOGGER_CLIENT_ID }}
          BLOGGER_CLIENT_SECRET: ${{ secrets.BLOGGER_CLIENT_SECRET }}
          BLOGGER_REFRESH_TOKEN: ${{ secrets.BLOGGER_REFRESH_TOKEN }}
          BLOGGER_BLOG_ID: ${{ secrets.BLOGGER_BLOG_ID }}

Remember that GitHub cron uses UTC. For 10:00 AM in India (UTC+5:30), the cron is 30 4 * * *. Scheduled runs can also start 10 to 30 minutes late, so I schedule a little earlier than I need.

Error 1: `GEMINI_API_KEY is not set`

My first run failed in 13 seconds with exactly that message. The key was in my local .env, but GitHub never sees your .env file.

Fix: add it under Settings → Secrets and variables → Actions → New repository secret.

Secret names can only contain letters, numbers and underscores. If GitHub rejects the name, you probably pasted the whole NAME=value line into the name field.

Error 2: the model was retired (HTTP 404)

The next run failed with:

This model models/gemini-2.0-flash is no longer available.

Model names get retired. Hard-coding one means your automation silently dies one day.

Fix: read the model from an environment variable, and if the API returns 404, ask the ListModels endpoint for a current "flash" model that supports generateContent, then retry.

import os, requests

def pick_model(api_key):
    url = "https://generativelanguage.googleapis.com/v1beta/models"
    r = requests.get(url, params={"key": api_key}, timeout=30)
    r.raise_for_status()
    models = [
        m["name"] for m in r.json().get("models", [])
        if "flash" in m["name"]
        and "generateContent" in m.get("supportedGenerationMethods", [])
    ]
    if not models:
        raise RuntimeError("No usable Gemini flash model found")
    return sorted(models)[-1]

model = os.getenv("GEMINI_MODEL") or pick_model(os.environ["GEMINI_API_KEY"])

I also retry 3 times and validate the output so a half-written post never gets published.

Error 3: the refresh token that expires

If your Google OAuth app is in Testing mode, refresh tokens expire after about 7 days. Your automation works all week, then dies.

Fix: in Google Cloud Console, open the OAuth consent screen and move the app to In production. Then generate a new refresh token and update it in both .env and the GitHub Secret.

Making it safe to run daily

Idempotency: save each post as posts/<date>-<slug>.md and skip if today's post already exists, so a manual re-run does not create duplicates.
Quality guardrails: reject drafts that invent personal claims like fake clients or made-up percentages.
Fail soft on images: if the image fetch fails, publish without one instead of failing the whole run.
Test as a draft first: run once manually with drafts enabled, check Blogger, then switch to publishing.
Never print secrets in logs.

A note on quality

Automation should not mean spam. I keep topics tied to real skills, ask for practical guides instead of invented stories, and read the output before trusting it. Search engines care about useful content, not volume.

Wrapping up

The pipeline is small, but the lessons are general: secrets live outside your repo, model names expire, and OAuth apps in testing mode expire too.

If you want to see where my posts end up, check my portfolio at ritika-rajput-portfolio.vercel.app, and my videos on RitikaMoments.

Have you automated something similar? What broke first for you?

3 Bugs I Fixed in My React Portfolio (Mobile Menu, Canonical Tags, Image Sizing)

Ritika Rajput — Wed, 28 Oct 2026 07:15:27 +0000

I recently built my portfolio with React, TypeScript, Tailwind and Vercel. After launching it, I hit three bugs that were easy to miss but hurt real visitors. Here is what went wrong and how I fixed each one.

1. The mobile menu that never opened

On phones, tapping the hamburger icon dimmed the screen and turned the icon into an "X", but the menu links never appeared.

What I learned:

A dimmed backdrop plus an "X" means your state toggle works. The problem is the panel itself.
Check your CSS variables first. If something like --mobile-menu-bg is undefined, the panel can be transparent.
Animations that start at opacity: 0 can get stuck invisible.
A parent with overflow: hidden or transform can clip an absolute child.

The fix: render the panel as position: fixed, give it a solid background with a fallback value, and keep it above the backdrop.

<div
  id="mobile-menu"
  className="fixed inset-x-3 top-20 z-[110] rounded-2xl bg-[var(--mobile-menu-bg,#0b1530)] p-2"
>
  {links.map((l) => (
    <a key={l.href} href={l.href} className="flex min-h-[48px] items-center px-4 text-white">
      {l.label}
    </a>
  ))}
</div>

Also keep touch targets at least 44px, close the menu on link click, outside click and the Escape key, and add aria-label and aria-expanded to the button.

2. Google refused to index my /portfolio page

Search Console said: "Alternate page with proper canonical tag".

URL Inspection showed the user-declared canonical was my home page (/) instead of /portfolio. A single hard-coded canonical in index.html was shared by every route, so Google treated each page as a duplicate of the home page.

The fix: set the canonical per route.

import { useEffect } from "react";

const SITE = "https://your-domain.com";

export function useCanonical(path: string) {
  useEffect(() => {
    let link = document.querySelector<HTMLLinkElement>('link[rel="canonical"]');
    if (!link) {
      link = document.createElement("link");
      link.rel = "canonical";
      document.head.appendChild(link);
    }
    link.href = `${SITE}${path}`;
  }, [path]);
}

Give every route its own title and meta description too, and list all routes in sitemap.xml.

3. Images that looked wrong on different screens

My profile photo was too big on small phones and too small on large screens.

The fix: size it with clamp() and keep the aspect ratio fixed.

.profile-photo {
  width: clamp(200px, 60vw, 440px);
  aspect-ratio: 4 / 5;
  object-fit: cover;
  object-position: top;
}

Add width and height attributes to avoid layout jumps, set max-width: 100% on images, and always include <meta name="viewport" content="width=device-width, initial-scale=1">.

Quick checklist

[ ] Test the mobile menu on a real phone, not only desktop resize
[ ] Check the canonical tag on every route
[ ] Verify pages in Google Search Console's URL Inspection
[ ] Test at 360px, 390px, 768px, 1280px and 1920px widths

Wrapping up

None of these bugs showed up in a quick desktop check, but they affected real users and search visibility. Test on phones, and inspect what Google actually sees.

You can see the portfolio here: ritika-rajput-portfolio.vercel.app

I also share videos on my YouTube channel, RitikaMoments.

What was the last "invisible" bug you found in your own project? Tell me in the comments.

How I built and launched my portfolio website as a beginner, using AI tools

Ritika Rajput — Fri, 09 Oct 2026 06:47:52 +0000

Hi, I'm Ritika Rajput, a web developer, video editor and social media manager from India. I wanted a portfolio website, but I don't write HTML, CSS or React from scratch. So I built it with AI tools. Here is what that really looked like, including what went wrong.

Live site: https://ritika-rajput-portfolio.vercel.app

The tools I used

Replit Agent to generate the first version
VS Code with OpenCode (an AI coding agent) for later changes
GitHub to save and version my code
Vercel to host the site
Supabase for the database behind my admin panel
Google Search Console to get the site indexed

What went wrong, and what I learned

1. AI writes placeholder text that looks real. My first version had generic lines about "an independent creative studio" and even an invented year ("Since 1998") on a client project. I had to read every line and replace it with true information. Always review what the AI writes about you.

2. My first deployment failed. Vercel stopped with the error "PORT environment variable is required". The fix was adding the missing environment variables in the Vercel settings and redeploying. [Add one line about how you felt or how long it took.]

3. Database security is not optional. My Supabase tables use Row Level Security. For now they allow public reading only, and I plan to add a proper login before allowing any writes.

4. Be honest about your skills. I removed the fake percentage bars from my Skills page and listed the tools I actually use.

5. SEO basics are small but important. I added page titles, meta descriptions, alt text for images, a sitemap.xml and a robots.txt.

What I built

Pages: Home, About, Skills, Blog, Projects and Contact, plus a hidden admin panel for managing content.

My first client project is a website for Nirmal Family Restaurant & Party Hall: https://nirmal-restaurant.vercel.app/

What is next

I want to make my contact form send real messages, publish real blog posts, and add more projects (video editing, graphic design and social media).

If you are a beginner and think an AI-built website is not "real", I disagree. It is real when you review it, test it and understand what you ship. Feedback is very welcome!

DEV Community: Ritika Rajput

Making My Portfolio Less Boring: 4 Small Redesigns That Made a Big Difference

1. Replace "Coming soon" with real work

2. Use the empty space next to a big heading

3. Turn a row of small links into cards

4. Check your contrast

A bonus: make every page do a different job

My rules for every change

Wrapping up

What I Learned Using Free AI Coding Agents on a Real Portfolio (OpenCode and Kilo)

1. Ask for a read-only diagnosis first

2. Keep every prompt small

3. Always tell the agent not to commit or push

4. Typecheck passing does not mean the build passes

5. Don't let the agent test in a browser

6. Watch out for Windows and PowerShell

7. "Already implemented" needs checking

8. Free models have limits

9. Never paste secrets to an agent

My simple workflow now

Wrapping up

Helping Google Know Who I Am: SEO for a Developer Portfolio (Person Schema, Canonical Tags, sameAs)

1. Each page needs its own canonical tag

2. Unique titles and descriptions per route

3. Add Person structured data (JSON-LD)

4. Link your profiles to each other

5. Make the content itself clear

6. Tell Google about the changes

What I'm watching now

Quick checklist

Wrapping up

How I Use Supabase as a Simple CMS for My Portfolio Blog

1. Create a posts table

2. Add a storage bucket for cover images

3. Read the posts in your frontend

4. Keep it secure with Row Level Security

5. Publishing a new post

Pros and cons

Final thoughts

I Automated My Daily Blog with GitHub Actions, Gemini and the Blogger API

The architecture

The workflow

Error 1: GEMINI_API_KEY is not set

Error 2: the model was retired (HTTP 404)

Error 3: the refresh token that expires

Making it safe to run daily

A note on quality

Wrapping up

3 Bugs I Fixed in My React Portfolio (Mobile Menu, Canonical Tags, Image Sizing)

1. The mobile menu that never opened

2. Google refused to index my /portfolio page

3. Images that looked wrong on different screens

Quick checklist

Wrapping up

How I built and launched my portfolio website as a beginner, using AI tools

The tools I used

What went wrong, and what I learned

What I built

What is next

Error 1: `GEMINI_API_KEY is not set`