DEV Community: Ama

# How to Apply for the GitHub Student Developer Pack Without Getting Rejected 🚀

Ama — Wed, 20 May 2026 17:38:13 +0000

In the previous post, I showed what you actually get from the GitHub Student Developer Pack and why it’s worth claiming if you’re learning to code.

Now let’s talk about the important part:

How do you actually get approved?

Because yes, GitHub can reject your application if your profile looks messy, your name doesn’t match your documents, or your account information feels suspicious.

So before you smash the “Apply” button, fix the basics first.

1. Set your legal name on GitHub 🪪

First, go to:

https://github.com/settings/profile

In the Name field, write your real legal name.

Not your nickname or backend_god_777
Your actual name.

This matters because GitHub may ask you to verify your student status with a document, and the name on your GitHub profile should match the name on that document.

Don’t lie here. It’s not worth it. If your name doesn’t match, you’re basically asking the verification system to slap your application into the rejection bin.

2. Fill in your billing information, but don’t add a card 💳

Next, go to:

https://github.com/settings/billing/payment_information

Scroll to Billing information and fill it in properly.

You need to add:

First name
Last name
Real address
City
Country
State / Province
Postal / ZIP code

The VAT / GST ID field can be left empty if you don’t have one.

Important: you don’t need to add a payment card for this step. Just fill in the billing information so your account looks complete and consistent.

Again, don’t write random nonsense here.

If your GitHub profile says one thing, your billing information says another thing, and your student document says something completely different, the verification system will not magically trust you.

It will probably just reject you and go drink coffee somewhere.

3. Apply for GitHub Education benefits 🎓

Now go to:

https://github.com/settings/education/benefits

This is where you apply for the GitHub Student Developer Pack.

Fill in the required information carefully. Choose your school/college/university, add the requested details, and submit your application.

GitHub may ask you to verify that you’re actually a student. Depending on your case, this can include things like a student email, school-issued document, student ID, transcript, or another proof of enrollment.

Make sure your document is readable, current, and matches the name you added earlier.

This is not the moment to upload a blurry potato photo taken from across the room.

4. Prepare a proper student document 📄

Before submitting the application, make sure your proof of student status actually looks official.

In my case, the document had:

my first name and last name
my class / grade
the academic year
the issue date of the certificate
the signature of an authorized person
the official blue round stamp / seal

That last part matters. A plain document with just your name typed on it may not be enough. GitHub needs to see that it came from a real educational institution, not from your “trust me bro” department.

Also, make sure the document is readable. No blurry photos, no weird angles, no dark screenshots where the text looks like ancient cave writing.

Your name on the document should match the legal name you added to your GitHub profile earlier. If the names don’t match, don’t be surprised if the verification system throws your application into the shadow realm.

5. Check your email 📩

After submitting your application, check your email.

If everything was submitted correctly, GitHub should send you a confirmation email saying they received your application. It may also give you an estimated date for when you should get a final response.

If you get rejected, don’t panic.

Read the reason carefully. Usually, it’s something boring but fixable:

name mismatch
unclear document
expired proof
wrong school information
incomplete GitHub profile
document doesn’t clearly show active enrollment

Fix the issue and apply again properly.

The goal is not to “trick” GitHub.

The goal is to make your information clean, consistent, and easy to verify.

6. Don’t rush the application 🧠

A lot of people get rejected because they apply too fast with a half-empty GitHub profile and messy account details.

Before applying, quickly check this:

Your GitHub name matches your document
Your billing information is filled in
Your school information is correct
Your document is clear and readable
Your proof shows that you’re currently a student
Your email is accessible

Small details matter here.

The verification system is not your friend. It doesn’t understand “bro trust me.”

It wants clean information.

Give it clean information.

Final checklist ✅

Before applying, do this:

Go to https://github.com/settings/profile and set your real legal name.
Go to https://github.com/settings/billing/payment_information and fill in your billing information.
Go to https://github.com/settings/education/benefits and submit your application.
Check your email for updates.
If GitHub asks for extra verification, send a clear and valid document.

That’s it.

No magic.
No shady tricks.
No fake data.

Just make your account look real, consistent, and verifiable.

What You Actually Get from GitHub Student Developer Pack (No Corporate Fluff) ⚡

Ama — Wed, 20 May 2026 17:21:45 +0000

If you’re a student or just learning to code, please don’t start your dev journey by burning money on premium tools.

You don’t need to pay for every shiny “Pro” button you see.

The GitHub Student Developer Pack is basically a loot box for developers, except this one is legal, useful, and doesn’t ask your wallet to bleed 🫠

You get IDEs, hosting credits, cloud platforms, learning resources, monitoring tools, and a bunch of other stuff. But here’s the problem:

The official directory has a lot of tools.

And when you’re still learning, it’s easy to open the list and think:

“Cool… but what am I actually supposed to use?”

So I filtered out the noise and kept the stuff I’d actually care about if I were building backend APIs, Telegram bots, automation scripts, portfolio projects, or small SaaS experiments.

1. GitHub Copilot: amazing, but there’s a catch 🤖

Let’s talk about the AI elephant in the terminal.

GitHub Copilot Student is currently paused for new sign-ups.

If you already have access, nice. Keep using it.

If you’re applying now, don’t build your whole plan around it.

Copilot is useful🧠
It can save time🧠
It can help you move faster🧠

But it won’t magically turn bad fundamentals into clean code.

While Copilot Student is paused, you can still use:

Copilot Free
ChatGPT
Gemini
Notion AI
documentation
and the ancient senior-dev ritual: actually reading the error message 💀

AI is a tool.

Not a replacement for your brain.

2. JetBrains IDEs: probably the fattest win in the pack 🧠

This is the one I’d claim first.

The Student Pack gives you access to JetBrains tools like:

PyCharm Professional
WebStorm
IntelliJ IDEA Ultimate
DataGrip
PhpStorm
and more

If you’re learning backend, this is huge.

Python / FastAPI / Django?
Use PyCharm Professional.

Node.js / TypeScript / frontend-heavy work?
Use WebStorm.

Working with databases?
DataGrip will make you wonder why you were fighting raw database clients like a medieval peasant.

And most importantly:

No cracked IDEs.
No sketchy downloads.
No “why is Windows Defender suddenly judging my life choices?” moments 😬

Just proper tools.

3. Heroku: easy deployment without DevOps pain ☁️

Heroku gives students $13/month in credits for 24 months, which adds up to $312.

That’s actually useful.

You can host:

FastAPI apps
Express APIs
Django projects
Telegram bots
webhook servers
cron jobs
small portfolio backends

Heroku is great when you want to deploy something without spending three days wrestling with server config.

You push your code.
It runs.
You fix your actual bugs.

Beautiful little backend sandwich 🥪

4. DigitalOcean: when you want to learn real server stuff 🐧

DigitalOcean gives eligible new users $200 in credit for 1 year.

This is where things get more serious.

Use it when you want to learn:

Linux servers
SSH
Docker
Nginx
PostgreSQL
Redis
background workers
proper backend deployment

Heroku is “ship fast”.

DigitalOcean is “understand what’s happening under the hood”.

And if you want to become a strong backend developer, you need that under-the-hood knowledge.

Not immediately. But eventually, yes.

5. Azure: useful cloud credit with less billing anxiety 💳

Azure for Students gives you $100 in credit and access to a bunch of cloud services.

The nice part?

No credit card required.

That matters.

Because nobody wants to wake up to a surprise cloud bill that looks like a boss fight health bar.

Azure is useful if you want to experiment with:

app hosting
databases
serverless functions
cloud storage
enterprise-style cloud tools

I wouldn’t start here first as a beginner.

But it’s a good place to explore once you already understand the basics.

6. Sentry: know when your code explodes before users do 🔥

Sentry is one of those tools beginners ignore until something breaks in production.

Then suddenly it becomes very interesting.

With the Student Pack, you get a useful Sentry allowance for error tracking and performance monitoring.

Connect it to your backend and you can see:

what error happened
where it happened
how often it happened
which request caused it
what needs fixing first

This is the difference between:

“Bro, your app is broken.”

and:

“I already saw the error, fixed it, and deployed the patch.”

That second version makes you look much more professional.

7. Learning platforms: good, but don’t collect courses like trophies 📚

The pack also includes learning resources like Codédex and other education offers.

These can be useful. But don’t fall into the classic beginner trap:

Collecting courses instead of building projects.

A course is good if it helps you build something.

A course is bad if it becomes another way to avoid opening your code editor.

Use learning platforms to fill gaps.

Then go build.

That’s where the real XP is.

What I’d claim first

If you’re learning backend, I’d start with this order:

JetBrains IDEs
Heroku
DigitalOcean
Sentry
Azure
Notion / learning tools

This gives you a strong setup for writing, deploying, monitoring, and improving real projects.

Final verdict 🧩

Even with GitHub Copilot Student paused for new sign-ups, the GitHub Student Developer Pack is still absolutely worth it (absolute OP).

The JetBrains license alone is already a big win.

Add Heroku, DigitalOcean, Azure, Sentry, and learning resources on top, and it becomes one of the best free bundles you can get as a student developer.

So if you’re eligible, don’t sleep on it.

Claim the pack.

Pick a few tools.

Build something real.

Your portfolio won’t grow by itself.
How to apply: in this post

What You Actually Get from Google AI Pro (Beyond the Marketing)

Ama — Thu, 05 Mar 2026 12:11:01 +0000

Everyone lists the 2 TB and Gemini access, but that's just the box 📦. The real value is in the workflows it quietly unlocks—if you know where to look.

The real problem

Most productivity tools add more steps to your day. You subscribe for one shiny feature, but end up managing another app, learning new shortcuts, and fighting a different UI 😮‍💨. The promise of "AI assistance" often feels like more work, not less.

What I changed

I stopped treating it as a chatbot subscription and started treating it as a context engine 🧠. The goal isn't to have conversations with AI; it's to offload the mental overhead of starting, summarizing, and connecting information scattered across Google's ecosystem. The trade-off? You have to lean into Google's apps (Docs, Drive, Gmail) to get the full benefit.

Real workflow (step-by-step)

Dump everything into a dedicated Drive folder. I have a folder called _context. In goes every project brief, meeting note, spec sheet, and useful snippet I find. This isn't for organization—it's raw material 🗃️.
Start every new Doc with a command, not a thought. Instead of staring at a blank page, I write a prompt like: "Based on the files in the _context folder about [Project X], draft a technical approach focusing on error handling." It uses my past work as a template 🚀.
Use Gmail's "Help me write" for triage, not composition. I don't have it write full emails. I use it on dense threads with: "Summarize the key decisions and list action items for me." In 3 seconds, I know if I need to engage or not 📬.

Mistakes and gotchas

Mistake 1: Treating Gemini like a search engine. It's terrible for factual lookups 🔍. Its strength is synthesizing your content. Avoid asking "what is X?"; ask "based on my document Y, how would I approach X?"
Mistake 2: Ignoring the family plan structure. If you're paying solo, you're overpaying 💸. The 6-person family sharing is the secret. You can split the cost with trusted colleagues (everyone keeps their own account/data), making it one of the cheapest per-person AI tools available.

More about family plan is here

Final take

Don't buy it for the AI. Buy it for the 2 TB of unified storage, then use the AI to make that storage actively useful. The intelligence is a bonus that only works if you feed it your own context.

TL;DR 🧾

The core benefit is using 2 TB of Drive storage as your team's or your own active, AI-accessible memory.
Real value comes from prompting Gemini with your documents and emails, not general knowledge.
Always use the Family Plan; share with 5 others to drop the effective cost to ~$3.33/person/month.
It's a system for reducing startup friction on tasks, not a magic idea generator.

What's the one annoying task it's actually helped you automate?

Stop paying OpenAI to transcribe your voice notes (My offline Telegram bot stack) 🎙️

Ama — Wed, 04 Mar 2026 13:45:16 +0000

Every tutorial on building an AI Telegram bot right now uses the exact same lazy architecture:

User sends a voice message.
Bot downloads the .ogg file.
Bot sends the file to OpenAI's Whisper API.
You get billed per minute of audio.

This is fine if you are building a quick prototype. But if you actually use your bot every single day, you are burning money on a task your own CPU can do for free. Not to mention the privacy nightmare of shipping all your personal audio logs to a third-party cloud.

The local alternative ⚙️
I wanted to build a Telegram interface for the Nomi API. I heavily rely on voice messages, so I needed speech-to-text.

Instead of defaulting to a paid API, I built the entire transcription pipeline locally using Vosk and FFmpeg.

The workflow is dead simple:

Telegram sends the .ogg voice note.
FFmpeg runs a local process to convert it to a .wav file with the correct sample rate.
The offline Vosk model reads the file and returns the text.
Then the text is sent to the LLM.

code Python

# The core logic is just wrapping the offline tools
# No network requests, no API keys for the transcription

async def process_voice(file_path):
    wav_path = convert_ogg_to_wav_ffmpeg(file_path)
    text = await run_vosk_transcription(wav_path)
    return text

Why this matters 🧱
Network latency disappears. Your server isn't waiting on a cloud provider to process an audio file. The transcription happens instantly, offline, and costs absolutely zero dollars.

More importantly, it forces you to understand your tools. Setting up async subprocesses for FFmpeg inside a Telegram bot (I use aiogram) teaches you way more about backend architecture than just making another HTTP request to OpenAI.

You can find the entire implementation in my NomiAssistantTG repo. It handles the Telegram async loop, the offline voice processing, and the API connections.

Why I build micro-tools (and a quick favor) 🤝
Developers default to paid SaaS tools because setting up local binaries like FFmpeg and Vosk feels like a headache.

I spend my time taking those headaches, wrapping them into clean, reusable Python code, and dropping them on GitHub. My repositories aren't theoretical frameworks; they are the actual tools I use to bypass expensive API limits.

If my NomiAssistantTG code just saved you a monthly OpenAI Whisper bill, or gave you a working async boilerplate for your next Telegram bot, consider dropping a sponsorship on my GitHub:

👉 Sponsor AmaLS367 on GitHub

Your support directly buys the time I need to keep breaking things, reading awful documentation, and open-sourcing production-ready templates so you don't have to.

TL;DR

Stop sending basic audio transcription to the cloud.
Use FFmpeg to normalize Telegram voice notes.
Use Vosk for free, offline, instant speech-to-text.
Keep your architecture lean.

Are you still using Whisper API for personal projects, or have you moved to local models? Let me know 👇

I deleted my entire AI microservice and just used Postgres (here is why) 🐘⚡

Ama — Sun, 01 Mar 2026 11:04:22 +0000

A few months ago, I needed to build a feature that everyone is asking for right now: "Let our users chat with their messy data." (In my case, it was a massive dump of chaotic customer support tickets).

If you Google how to build this, the internet will immediately try to sell you a 5-tier architecture:

You need a Vector DB for embeddings.
You need a graph database for relationships.
You need LangChain to glue it together.
You need a separate Python microservice to run it all.

I fell for it. I built it.
And two weeks later, I was dealing with the most annoying bug in modern engineering: State mismatch.

A user would delete a ticket in our main database, but the vector representation of that ticket still lived in our Vector DB. The AI kept hallucinating answers based on deleted data.

The "Aha" Moment 💡
Syncing data between a relational database and a dedicated vector database is a nightmare. You have to write custom webhooks, handle failed retries, and pay for two separate servers.

So, I just threw it all away.

I stopped treating AI like some magical entity that requires a bespoke ecosystem, and went back to the most reliable tool in the backend world: Postgres.

Postgres + pgvector = Peace of Mind 🧘‍♂️ (and its not a joke)
Instead of sending data across the internet to a third-party vector store, I just enabled the pgvector extension.

My data and my embeddings now live in the exact same table:

CREATE EXTENSION vector;

CREATE TABLE support_tickets (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid REFERENCES users(id) ON DELETE CASCADE,
  issue_text text,
  embedding vector(1536) -- OpenAI's embedding size
);

Look at that ON DELETE CASCADE.
If a user deletes their account, their tickets disappear. Because the tickets disappear, the embeddings disappear. Instant, ACID-compliant state management without writing a single line of sync logic.

Dumping the heavy frameworks 🗑️
Once everything was in Postgres, I realized I didn't need LangChain or LlamaIndex either.

Most AI frameworks try to do too much. They hide the actual API calls behind layers of abstraction, making debugging impossible.

Now, my entire "RAG" pipeline is just a raw SQL query and a standard API fetch:

User asks a question.
Turn the question into an embedding.
Run a cosine similarity search directly in SQL:

SELECT issue_text 
FROM support_tickets 
ORDER BY embedding <=> $1 
LIMIT 5;

Feed those 5 results into the OpenAI/Anthropic API with a strict JSON schema.

That's it. No microservices. No $80/month Vector DB bills. Just a regular monolithic backend doing its job efficiently.

Why I'm sharing this (and how you can support) ☕
The tech industry loves hype. We are constantly pushed to adopt the newest, most complex tools, even when a boring 20-year-old technology does it better.

I spend a lot of my time testing these architectures, making the mistakes, and stripping away the marketing fluff so you can just build things that actually work in production.

If this post just saved you from an unnecessary architecture rewrite, a massive SaaS bill, or a weekend of debugging sync errors, consider sponsoring my work on GitHub:

👉 Sponsor AmaLS367 on GitHub

Sponsorships give me the freedom to keep experimenting, breaking things, and open-sourcing production-ready boilerplates that save you time.

TL;DR
Don't over-engineer your AI features.
Dedicated Vector DBs often introduce data-sync nightmares.
pgvector keeps your embeddings ACID-compliant.
Ditch heavy AI frameworks; raw API calls + SQL are easier to debug and maintain.

I’m really curious — how are you managing your embeddings right now? Are you using a separate DB or keeping it monolithic? Let me know below! 👇

I ship a lot of API/webhook integrations. Here’s how I make them NOT hurt in production 🔥

Ama — Fri, 27 Feb 2026 13:19:06 +0000

I ship a lot of API/webhook integrations. Here’s how I make them NOT hurt in production 🔥

If you do freelance backend long enough, you start noticing a pattern:

Clients don’t pay for “beautiful code”.
They pay for it working tomorrow.

And webhook integrations are the fastest way to get random chaos:

duplicate events
out of order delivery
retries that DDoS you
and the classic “it worked yesterday 🤡”

So here’s my real-world baseline for building webhook/API integrations that don’t wake me up at 3AM.

No theory. Just a practical checklist + a simple architecture that scales.

1) Assume the webhook will be duplicated. Because it will. ✅

If you process every incoming request as “unique”, you’re cooked.

Rule: every webhook must be idempotent.

That means you need an event id or a hash that lets you say:

“Seen it. Skipping.”

Real workflow:

extract event_id from payload (or generate a hash from stable fields)
store it with a status
on repeat: return 200 OK and do nothing

Because if you return 500, they will retry harder.

2) Acknowledge fast. Process async. ⚡

A webhook handler that does real work inside the HTTP request is a trap.

It feels fine until:

your DB is slow for 5 seconds
the provider timeout hits
retries begin
now you’re processing the same event 5 times

My default:

Receive webhook
Validate signature / basic checks
Save event to DB (raw payload + metadata)
Return 200 OK fast
Process the event in a worker/job queue

This makes your system calm.

3) Store raw payloads. Future you will thank you 🧠

When something breaks, the client will say:

“I don’t know, it just didn’t send.”

If you don’t store raw payloads, you have no evidence and no replay.

I always store:

full raw JSON payload
headers (at least important ones)
provider name
received timestamp
processing status
error message if failed

Then you can:

replay events
debug edge cases
prove what happened

It turns “guessing” into “knowing”.

4) Security: verify signatures or don’t pretend it’s secure 🔒

If the provider supports signatures, verify them.

Not later. Not “we’ll add it after MVP”.

Right away.

Because otherwise you’re basically running:

public endpoint that triggers actions

That’s how you get spam, abuse, or worse.

5) Rate limits and backoff: retries are not your enemy, your implementation is 😅

When processing fails, don’t do instant retries like a maniac.

Use backoff:

1 min
5 min
30 min
2 hours
dead-letter queue (manual review)

Most integrations fail because:

temporary provider downtime
temporary DB issue
network nonsense

Backoff makes it survive like a tank.

6) Logging that actually helps, not “we logged something” 📝

I log at two layers:

Request layer

request id
provider
event id
status returned

Job layer

event id
job attempt
result
full error stack (if any)

And one extra rule:
If job fails, save a short human-readable error near the event record.

So later I can scan the DB and instantly see patterns.

7) My minimal scalable structure (simple but powerful)

I like separating responsibilities like this:

webhook_controller
accepts HTTP, validates, stores event, returns response fast
event_store
saves raw payloads, dedup keys, statuses
processor
contains business logic: “what do we do with this event”
adapters
provider-specific mapping (CRM A vs CRM B)
queue/worker
runs processing asynchronously with retry rules

This lets you add new integrations without rewriting everything.

You just add a new adapter.

Common production “gotchas” (learned the annoying way) 🤝

Out-of-order events

You might receive “updated” before “created”.

Solution:

allow upserts
store event history
process based on current state

Provider sends partial data

Sometimes they send only IDs and you must fetch details.

Solution:

use a “hydration step” in the worker (API pull)
cache if needed

Webhook timeouts

If you process inside request, you lose.

Solution:

fast ACK, async processing

TL;DR 🧾

If you want webhook integrations that behave in production:

idempotency is mandatory
acknowledge fast, process async
store raw payloads
verify signatures
implement sane retries
log like you’ll debug it later (because you will)

If you’ve ever shipped webhooks in production, you already know:

it’s never “done”.

it’s “stable enough to survive real traffic” 😄

Drop your worst webhook horror story below 👇

What you can actually DO with Google AI Pro (real workflows) ⚡

Ama — Wed, 25 Feb 2026 18:24:41 +0000

Most posts about Google AI Pro sound like:

“2 TB storage 🤖
Gemini in Gmail 🤖
Gemini in Docs 🤖”

Cool.

But none of that matters until it saves you from something annoying in real life.

So here’s how I actually use it — not as a chatbot, but as a daily tool that quietly removes friction.

Gmail → from chaos to “ok I know what’s going on” 📬

You know those email threads where:

12 replies
half decisions
someone changed the scope
and you’re mentioned once in the middle

Before: reread everything like a detective 🕵️

Now I just ask:

What was decided here and what do I need to do?

And that’s it.

I get:

decisions
action items
things waiting for me

This is the first time an AI feature actually made my inbox calmer instead of louder.

Starting a project without staring at a blank page

Blank Docs page = fake productivity.

Now my flow is:

Create a technical plan for a Playwright-based monitoring tool with retries, logging and alerts.

It gives me a structure.

Not something I copy.

Something I react to.

That’s the difference.

It turns “ugh I need to start” into
“ok this is already moving”.

The underrated use: reading long technical stuff for me 🧠

Client specs.
Random API docs.
Some integration written in… a very creative way.

Instead of scanning everything:

What are the risky parts?
What is unclear?
What will break in production?

That question alone saved me from writing the wrong thing more than once.

And that’s hours of life.

Google Drive became my external memory 🗂️

This part is low-key insane.

I dump there:

old project notes
architecture drafts
random research
useful snippets

Then:

Based on my previous automation projects, suggest a structure for this new one.

You’re no longer prompting a model.

You’re prompting your past self.

That feeling is wild.

Research without the 37-tab anxiety 🌐

My normal research looked like:

open tabs → open more tabs → forget why I opened the first tab.

Now:

Compare these approaches for browser automation in production. Focus on stability and scaling.

I still open sources.

But only the ones that matter.

Less noise. Same depth.

Coding use (not the way people think) 💻

I don’t use it for:

“write me a function”.

I use it for:

What kind of race condition can happen here?

Is this module boundary bad?

How would you refactor this safely?

It’s like having a second brain for architectural thinking.

And it never gets tired.

2 TB storage changed one stupid habit ☁️

I stopped deleting things.

Seriously.

Now I keep:

datasets
recordings
project archives
experiments

Which means:

my past work is always available → AI can use it → better outputs later.

Before I optimized for space.

Now I optimize for context.

Family sharing = the most practical “AI scaling” move

Everyone has:

their own account
their own chats
their own workspace

But the plan is shared.

So it doesn’t feel like:

“paying for a tool”

It feels like:

a small private AI environment for people you work or live with.

The real shift

The biggest change is not the model.

It’s this:

AI is no longer a separate tab I visit.

It lives inside:

Gmail
Docs
Drive

Which I already use all day.

So instead of “using AI”
I just… work.

Who this is actually for

This setup makes sense if:

you juggle multiple projects
you read long messy things
you plan systems before coding
you reuse your own knowledge

Not if you just want:

“write me a tweet”.

What I’m testing next 🧪

Using Drive as structured long-term context
Full project planning inside Docs
Pushing it harder in real coding workflows

Will share what actually holds up in production life.

TL;DR

Google AI Pro became useful for me when I stopped treating it like a chatbot and started using it as:

inbox interpreter
project starter
context reader
external memory

Everything else is just features.

If you’re using it in a different way — I’m genuinely curious.
Always looking for workflows that remove friction ⚡

$20 subscription 6 people: Google One AI family sharing explained 😈✨

Ama — Wed, 25 Feb 2026 12:47:31 +0000

If you’re paying for Google AI Pro alone, you might be leaving value on the table.

Google lets you create a family group with up to 6 accounts total (1 manager + 5 members) and share certain Google services across that group. So one person pays, and multiple people can benefit — without mixing chats, because everyone still uses their own Google account.

This post explains what you actually get, what’s shared vs not shared, and how to set it up without drama 🙃

The idea (in one sentence)

One person buys Google AI Pro ($19.99/month), enables family sharing, invites up to 5 people, and each person uses Gemini from their own Google account (so chats and history don’t collide).

⚠️ Quick honesty check (before the “invite whoever” part)

Google calls it a family group and markets it as sharing with “people you love” / household. You can invite any Google account technically, but don’t be weird about it: invite people you trust, and assume Google expects it to be “family/household-style sharing.”

That said… yes: it’s not a shared login. Each member uses their own account, their own prompts, their own Drive, etc. ✅

What you get (the “why this is OP” list) 🔥

1) Up to 6 accounts total

1 family manager
up to 5 invited members Even pending invites count toward the limit.

2) Gemini benefits for family members (no extra cost)

Google’s own help docs literally say that family plan members on a Google AI Pro plan can enjoy AI benefits and features at no extra cost.

3) 2 TB storage (shared pool)

AI Pro includes 2 TB total storage across Google Drive / Gmail / Photos.

4) Gemini inside Google apps (Gmail / Docs / etc.)

Google has been rolling Gemini into apps like Gmail, Docs, Sheets, Slides, Meet for these plans (availability can vary by country/language).

5) Coding goodies (yes, Antigravity is in the bundle)

On the official subscriptions page, Google AI Pro includes higher access to a bunch of dev stuff like Gemini Code Assist / Gemini CLI / Jules and Google Antigravity.
(And yeah, Antigravity is their “agentic dev platform” thing — it’s getting real attention lately.)

What’s shared vs what’s NOT shared 🧠

✅ Shared

The membership benefits that are meant to be shareable across a family group (AI Pro perks)
The storage pool (2 TB) across the family group

❌ Not shared (important)

Your Gemini chats are not merged (different accounts → different chat histories) ✅
Your files are not visible to the manager unless you explicitly share them. Google states that others in your family won’t have access to your files unless you share directly.

So you get the benefits, but you don’t become roommates inside one account. Perfect.

Step-by-step setup (the clean way) 🛠️

Step 1: One person becomes the “plan manager”

They subscribe to Google AI Pro (currently shown as $19.99/month on Google’s subscription page).

Step 2: Create / manage your Google family group

As the family manager, you can invite up to 5 people.

Step 3: Turn on Google One family sharing

Google One supports sharing with up to 5 family members.

Step 4: Invite people (and they accept)

They accept the invite, and then they just use Gemini normally… on their own account.

Common gotchas (aka “why doesn’t it work for my friend?”) 😵‍💫

Country availability / rollout
AI features and integrations can vary by country/territory and rollout timing. Google AI Pro availability is listed as “150+ countries/territories” (check your region).
You hit the 6-person limit
It’s strict: 5 members + 1 manager max.
Storage confusion
Storage is a shared pool, but each person controls their own files. If someone is eating all the storage, you can’t delete their stuff — they need to clean up their own account.

My personal “best use” setup 😎

If you’re doing coding + content + life stuff:

Use Gemini Pro for research + planning + drafting
Use Gemini inside Gmail/Docs for annoying admin work
Use Antigravity / Code Assist / CLI for coding workflows (depending on what you like)
Enjoy the 2 TB and stop playing storage Tetris forever

TL;DR 🧾

Google family group = up to 6 accounts (manager + 5)
Google AI Pro = $19.99/month, includes 2 TB + Gemini in apps + dev tools
Family members can enjoy AI benefits at no extra cost
Chats don’t mix (separate accounts), and files aren’t visible unless shared

Sources

1: https://support.google.com/googleplay/answer/6317858?hl=en&utm_source=chatgpt.com "Join or leave a family on Google"
2: https://gemini.google/subscriptions/ "Google AI Pro & Ultra — get access to Gemini 3.1 Pro & more"
3: https://families.google/intl/en_ca/families/?utm_source=chatgpt.com "Stay Connected with a Family Account"
4: https://support.google.com/googleone/answer/14534406?hl=en "Use Google AI Pro benefits - Google One Help"
5: https://blog.google/products-and-platforms/products/google-one/google-one-gemini-ai-gmail-docs-sheets/ "Google One AI Premium: Gemini access in Gmail, Docs, Sheets and more"
6: https://www.theverge.com/news/822833/google-antigravity-ide-coding-agent-gemini-3-pro "Google Antigravity is an ‘agent-first’ coding tool built for Gemini 3 | The Verge"
7: https://support.google.com/googleone/answer/9004015?co=GENIE.Platform%3DAndroid&hl=en "Start or stop sharing with your family - Android - Google One Help"
8: https://support.google.com/googleplay/answer/6286986?co=GENIE.Platform%3DAndroid&hl=en&utm_source=chatgpt.com "Manage your family on Google - Android"

♻️ Persisting Login Sessions in Headless Playwright Automation

Ama — Mon, 02 Feb 2026 16:24:37 +0000

Logging into websites every single run is the fastest way to:

🚫 trigger anti-bot systems
🧩 face endless CAPTCHAs
🔒 get accounts locked
🐌 slow down your scraper

The correct pattern is simple:

In this article I will show how this works in a real project:

👉 https://github.com/AmaLS367/parts_info_collector

This project automates data extraction from Gemini’s web UI and keeps authentication between runs using a persistent browser profile.

🧠 The Core Idea

Instead of exporting cookies manually, Playwright can launch Chromium with a persistent user profile directory.

That directory stores:

cookies 🍪
localStorage
IndexedDB
login tokens
session metadata

Once created, it becomes your reusable authenticated identity.

📂 How the Project Does It

In parts_info_collector, authentication is handled via:

a user-data/ directory
first interactive run via first_start.bat
manual login to Gemini
all next runs reuse the same browser profile

So the flow is:

1️⃣ Run once with UI
2️⃣ Log in manually
3️⃣ Browser profile is saved
4️⃣ Next runs are headless and already authenticated

No repeated login.
No constant CAPTCHA hell 😌

🔐 Persistent Context in Playwright

This is the key API:

browser_context = playwright.chromium.launch_persistent_context(
user_data_dir="user-data",
headless=True
)

That single folder is everything.

If it exists, Playwright loads it.
If not, you run in visible mode and authenticate.

🧑‍💻 First Run: Create the Session

In the project, the first launch happens with UI enabled so you can log in:

browser_context = playwright.chromium.launch_persistent_context(
user_data_dir="user-data",
headless=False
)

You open Gemini, authenticate manually, and close the browser.

From that moment:

📁 user-data/ contains your session.

♻️ All Next Runs: Fully Headless

Subsequent executions simply reuse the same folder:

browser_context = playwright.chromium.launch_persistent_context(
user_data_dir="user-data",
headless=True
)

You are already logged in.

No forms.
No credentials.
No redirects.

⚠️ What Happens When the Session Expires?

Eventually cookies die.

The project handles this operationally:
you delete user-data/
or rerun first_start.bat
login again
profile is recreated

Simple, manual, and reliable.

You can extend this with:

detecting redirect to /login
checking DOM markers
auto-relogin logic
alerting

🛡️ Why Persistent Profiles Beat Cookie Dumps

Using a persistent profile directory is stronger than just exporting cookies:

✅ keeps IndexedDB tokens
✅ survives browser restarts
✅ mimics real user Chrome profile
✅ less suspicious than scripted logins
✅ perfect for long-running monitors

🚀 When You Should Use This Pattern

This approach is ideal for:

📊 price monitors
🤖 automation bots
🧠 AI web scrapers
📈 background workers
🔁 periodic collectors

Anything that runs for weeks.

🔗 Real Repository

Full project:

👉 https://github.com/AmaLS367/parts_info_collector

🧾 TL;DR

✅ use launch_persistent_context
✅ store profile in user-data/
✅ login once manually
✅ reuse forever
✅ refresh only when expired

🔍 Monitoring Bybit P2P USDT/RUB prices with Playwright network interception + Telegram alerts (Python)

Ama — Sun, 01 Feb 2026 13:25:49 +0000

If you have ever tried to “scrape” a modern website, you know the pain: the UI looks simple, but the data is loaded dynamically, and the DOM changes every two minutes 😅

⚡ What this tool does

You set a threshold like 71.50 RUB.
The script checks the current best USDT/RUB buy offer and notifies you in Telegram if the price is below that level.

Core flow:

🧭 open the Bybit P2P page
🕵️ listen to network responses
🧾 parse JSON from the P2P API response
📉 compare the best price with your threshold
📩 send Telegram message

No fragile selectors. No DOM gymnastics. Just data.

🧰 Setup

Install dependencies:

pip install -r requirements.txt
playwright install

Create .env:

BOT_TOKEN=your_telegram_bot_token
CHAT_ID=your_chat_id

Run:

python main.py

Then enter your threshold when the script asks for it.

🧠 The key idea: intercept the JSON response

Bybit P2P UI is basically a shell. The real data is coming from an internal endpoint.

So the strategy is:

open the page
subscribe to Playwright response events
filter responses by URL (the internal API endpoint)
call response.json()
extract offers and prices

This is usually more stable than DOM scraping because you rely on the same payload the app uses internally.

📦 Why network interception beats DOM scraping

DOM scraping often breaks because:
class names change
elements are lazy loaded
content is rendered differently by region or language
the site adds random wrappers

Network interception is cleaner:

✅ data structure is consistent
✅ you get structured JSON
✅ fewer moving parts
✅ easier debugging

If the endpoint changes, you update one filter. Not 20 selectors.

📩 Telegram alerts in 10 seconds

Telegram sending is just a POST request to:

https://api.telegram.org/bot/sendMessage

Payload:

chat_id
text

Add a timeout so your monitor loop never hangs.

Result: when the best price crosses your threshold, you get a nice message instantly 🚀

If you want to evolve this tool, here are easy upgrades:

🧽 deduplicate notifications so you do not spam yourself
🧷 move threshold into .env or CLI args
🧪 add a --once mode to run a single check
📊 store history to a simple CSV for analysis

✅ Wrap up

If you are scraping a dynamic website and the data comes from JSON calls, intercepting the network layer is often the most robust solution.

This project is a tiny example of that approach:

Playwright for browser and network events
JSON parsing for structured data
Telegram for instant notifications

Repo again: https://github.com/AmaLS367/bybit-p2p-price-monitor

If you have ideas for improvements or want to contribute, PRs are welcome 💪🔥