DEV Community: Aswini S M

# Starting AWS From Scratch: My Day-Zero Roadmap

Aswini S M — Wed, 15 Jul 2026 05:15:51 +0000

I'm Aswini — self-taught in frontend development (React, Tailwind, JavaScript) and Java, currently prepping for software development placements.

And as of today, I know almost nothing about AWS.

I've seen the acronym on every second job description. I've watched "AWS in 10 minutes" videos and understood maybe 40% of them. I've felt that specific kind of anxiety where a skill feels mandatory but also feels like a locked door with no obvious key.

So instead of quietly panicking about it, I'm doing what I did with React and Java: starting from zero, in public, and writing down the roadmap before I actually walk it. If it works, this becomes a useful trail for someone else starting at the same zero. If I get something wrong, hopefully someone corrects me in the comments before I get too far down the wrong path.

Why I'm Doing This Publicly

When I taught myself frontend development, the most useful posts I found weren't from people who'd mastered React for five years — they were from people one or two steps ahead of me, writing about what just confused them. That's the post I want to become for AWS.

Also, plainly: writing "I will learn AWS" in private is easy to quietly abandon. Writing it here means I have to show up with an update.

What I Actually Know Right Now (Baseline)

Being honest about the starting line:

I know cloud computing exists so companies don't have to manage physical servers themselves
I roughly know AWS, Azure, and GCP are the big three
I've heard of EC2, S3, and Lambda as names — I could not explain what any of them actually do if you asked me right now
I don't yet understand things like regions, availability zones, or IAM at all

That's it. That's the whole baseline.

My Roadmap (In the Order I'm Attempting It)

1. Cloud Computing Fundamentals — Before Touching AWS at All

Before opening the AWS console, I want to actually understand what "the cloud" means underneath the marketing language: what a server is, what "on-demand" really means, and why companies pay for this instead of owning hardware. I'd rather spend a few days here than get lost in AWS's console with zero mental model.

2. AWS Free Tier Account Setup

Setting up the free tier account, and — importantly — reading exactly what's free and for how long, so I don't accidentally get a bill because I misunderstood a limit. This step is boring but non-negotiable.

3. Core Services, One at a Time

Instead of trying to learn "AWS" as one giant subject, I'm picking a small number of services to actually get hands-on with first:

S3 — storage, because it seems like the easiest on-ramp
EC2 — virtual servers, because it comes up constantly in interviews and job descriptions
IAM — because apparently half of real-world AWS mistakes are permission-related, so understanding this early feels important rather than optional

4. Build One Small, Real Thing

Reading documentation without building anything never sticks for me. So the plan is to deploy something small and real — even just a static site on S3 — so the concepts have somewhere to attach themselves in my head.

5. Understand Where AWS Fits for a Fresher, Not Just a Cloud Engineer

I'm not applying for cloud engineering roles specifically — I'm a fresher targeting general SDE roles. So part of this journey is figuring out realistically how much AWS a fresher actually needs to know, versus what's nice-to-have. I suspect the honest answer is "less than it feels like from job descriptions," but I want to find that out for myself instead of assuming.

What I'm Nervous About

Mostly: that this becomes another tab that stays open for three weeks and quietly closes. Writing this post is partly a way of making that harder to do quietly.

I'm also nervous about the classic beginner trap — reading about AWS for hours without ever actually clicking around in the console, which teaches you vocabulary but not intuition.

What's Next

Part 2 of this series will be the "reality check" post — what actually happened when I opened the console for the first time, what confused me that I didn't expect, and whether my roadmap survived contact with reality (roadmaps rarely do).

If you've learned AWS as a fresher — especially without a cloud-specific job in mind — I'd genuinely like to hear what you wish someone had told you on day zero. Drop it in the comments; it might save me a wrong turn.

Following along? This is the first post in a series documenting my AWS learning journey from absolute zero. Part 2 coming once I've actually opened the console.

5 AI Tools Every "Vibe Coder" Needs in Their Bookmarks (2026 Edition)

Aswini S M — Sun, 14 Jun 2026 07:39:36 +0000

Build faster, design better, and ship like it's 2030.

21st.dev– A massive library of ready-made React/Tailwind components, plus the exact prompt to feed your AI agent
v0.app – Vercel's AI builder that turns a single prompt into a deployable full-stack app
glass3d.dev – Instantly generate trendy 3D glassmorphism effects and grab the CSS
60fps.design – A goldmine of real app animations to copy for buttery-smooth UI
Greta.sh – Describe your idea once, get a complete app with database, auth, and hosting

Why Everyone's Talking About "Vibe Coding"

Back in February 2025, AI researcher Andrej Karpathy casually posted about a new way of building software: describe what you want, let the AI write it, and "forget that the code even exists." That one post turned into a movement — by the end of 2025, "vibe coding" had been named Collins Dictionary's Word of the Year, with search interest jumping by thousands of percent.

Here's the catch: vibe coding is only as good as the inputs you feed your AI agent. Vague prompts get vague results. But hand it curated components, ready-made design systems, and real reference UIs — and suddenly your output looks (and works) like an actual product. That's exactly where these five sites come in.

1. 21st.dev — The Component Library Built for AI Agents

Think of it as an npm registry, but for UI. 21st.dev hosts a huge collection of React/Tailwind components — heroes, pricing tables, navbars, 3D backgrounds — that you can browse and drop straight into your project.

The real magic is its "Magic" AI agent integration: type /ui followed by a description inside Cursor, Windsurf, or VS Code, and it pulls a matching component and writes it into your codebase in your existing style. Millions of developers already use it as their default stop before building any UI section from scratch.

Best for: instantly upgrading the "boring" parts of your UI without reinventing the wheel.

2. v0.app — From Prompt to Production in Minutes

v0 started as Vercel's experiment in generating React components from text. By 2026, it's grown into a full agentic app builder: describe your idea in plain English, and v0 plans, builds, and wires up the frontend, backend, database, and authentication — then deploys it.

It's not just for developers either — product managers, founders, and designers use it to turn a "what if we built..." conversation into a live demo link in one sitting.

Best for: rapid prototyping, MVP validation, and turning an idea into a clickable demo before your next meeting.

3. glass3d.dev — Glassmorphism, the Easy Way

Glassmorphism — that frosted, semi-transparent "liquid glass" look — is everywhere right now, from Apple's design language to countless SaaS landing pages. glass3d.dev lets you tweak sliders for blur, color, and texture, watch the 3D glass effect update live, and copy the finished CSS straight into your project.

Best for: adding a premium, modern "glass card" feel to dashboards, modals, and hero sections without fighting backdrop-filter syntax.

4. 60fps.design — Steal Animations From the Best Apps

Good UI isn't just static — it's how things move. 60fps.design is a curated library of over 1,200 motion and micro-interaction clips pulled from top iOS, Android, and web apps: onboarding flows, button presses, loading states, gesture transitions. Tens of thousands of designers and engineers follow it for weekly inspiration drops.

Best for: benchmarking your app's "feel" against industry leaders — or showing your AI agent exactly the kind of transition you want.

5. Greta.sh — Your Full-Stack App, One Prompt Away

Built by a former Amazon/LinkedIn engineer, Greta takes the vibe-coding pitch to its logical extreme: type what you want — a booking system, a CRM, a personal blog — and it generates the UI, backend logic, database, and integrations, ready to deploy. It also syncs with GitHub, so developers can take the generated code and keep building manually from there.

Best for: non-technical founders and solo builders who want a working full-stack foundation fast — and developers who want a head start on boilerplate.

How to Stack These Together

A workflow that actually works:

Scaffold your app idea in v0.app or Greta.sh to get a working full-stack base.
Swap in polished components from 21st.dev for anything that still looks generic.
Add glass effects from glass3d.dev to cards, modals, and navbars for a premium look.
Reference 60fps.design clips when prompting your AI agent for animations — "make this transition feel like the onboarding flow in [App X]" beats "add a nice animation" every time.

Final Thoughts

None of these tools replace understanding your code — AI-generated output still needs review, especially before it touches production. But for prototyping, portfolios, hackathons, and side projects, this stack can take you from blank page to live demo in an afternoon.

Which one are you trying first? Drop a comment below 👇

Suggested tags: #WebDev #AI #VibeCoding #UIUX #Frontend #BuildInPublic #100DaysOfCode

# I Built a Full-Stack App Used by 500+ Real Users as a College Student — Here's What Nobody Tells You

Aswini S M — Fri, 01 May 2026 12:55:11 +0000

I almost didn't build this project.

I thought, "Who am I to build something for real users? I'm still in college. I barely know what I'm doing."

But I did it anyway. And now that app is actively used by more than 500 people.

This is the honest story of how I built it, what broke, what I learned, and what I wish someone had told me before I started.

If you are a beginner in web development, bookmark this. It will save you months.

Why I Built This in the First Place

Many community organizations — especially churches — manage their entire operations through WhatsApp groups, paper notices, and scattered spreadsheets. Events get missed. Announcements get lost. Media files live on someone's personal phone.

I saw this happening firsthand and thought — this is a real problem. And I know enough React and Node.js to attempt a solution.

So I started building.

Not because I was ready. Because the problem was real.

What I Built

A full-stack Church Management Web Application that handles:

Event scheduling and announcements
Dynamic media galleries (images, videos)
A secure admin dashboard for content management
Real-time updates for community members

The app is live. It has real users. And it has broken in real-world ways I never anticipated when I was writing code locally.

The Tech Stack (And Why I Chose It)

Frontend: React.js + Tailwind CSS
Backend: Node.js + Express.js
Database: MongoDB
Media Storage: Cloudinary
Deployment: Netlify (frontend) + Railway (backend)

I chose this stack because I was already learning React, and MongoDB made sense for flexible content structures. Cloudinary solved the media storage problem in one afternoon — which would have taken me weeks if I tried to build it myself.

How It Works — The Real Data Flow

Here is the actual flow from admin action to user screen:

Admin logs into the dashboard and adds an event or uploads media
Frontend sends an API request to the Express backend
Backend validates the request and processes it
Data is saved to MongoDB; images/videos are pushed to Cloudinary
When a user opens the app, the frontend fetches the latest data via REST APIs
The UI renders dynamically — no page refresh needed

Simple on paper. Surprisingly complex to get right in practice.

The 3 Moments Where Everything Broke

1. The API data mismatch that took me 2 days to find

My React frontend was sending data in one format. My Express backend expected a slightly different structure. The result? Silent failures — data that appeared to save but never actually did.

I spent two days debugging this before I realized I hadn't standardized my API payload format.

What I do now: Before writing a single line of frontend code, I define the exact request and response structure. I write it down. I test it in Postman. Then I build the UI around it.

2. State that refused to update when it should

Components were not refreshing after data changes. A user would submit a form and the UI would show the old data for another 10 seconds.

The root cause was poor state management — I was mutating state directly instead of triggering proper re-renders.

What I do now: I treat state as immutable. Every update creates a new object. I also use useEffect dependencies carefully instead of leaving them empty and wondering why nothing updates.

3. It worked locally. It broke for real users.

When I deployed, things that worked perfectly on my laptop started failing for users with slower connections or different browsers. Images would not load. API calls would time out.

This taught me the most important lesson of the entire project:

Local development is a lie. Always think about real network conditions.

What I do now: I test on throttled connections. I add loading states and error boundaries everywhere. I assume things will fail and handle it gracefully.

The Moment It Became Real

Three weeks after launch, a volunteer coordinator messaged me:

"The app saved us two hours of work this Sunday. Everyone knew exactly where to be."

That message hit differently than any grade I have ever received.

Your project is not real until a real person tells you it changed something for them. That is the bar. Not a deployment. Not a GitHub repo. A real person, real impact.

Numbers That Kept Me Going

500+ active users on the platform
Handles live event data every week
Reduced manual coordination effort significantly for the admin team
Taught me more in 3 months than a semester of coursework

What I Would Do Differently Today

If I rebuilt this from scratch, here is what I would change:

Add JWT-based authentication from day one (we had to retrofit this later — painful)
Set up proper error logging with a tool like Sentry before going live
Build a proper API contract document before writing any code
Add automated tests for critical API routes before deployment
Use environment variables correctly from the start (I hardcoded some things locally that caused embarrassing bugs)

The Real Lessons — The Ones No Tutorial Teaches You

1. Debugging is the actual job.
Writing code is maybe 30% of development. The rest is figuring out why it does not work.

2. Real users find bugs your tests never will.
Your localhost environment is not reality. Deploy early, even if it is ugly.

3. Data flow is everything.
If you understand how data moves from database to screen, you can debug anything. If you do not, you will always be guessing.

4. Shipping beats perfecting.
I was going to add authentication before launching. I was going to redesign the UI. I was going to add real-time notifications. Instead, I launched with what I had — and real feedback made it 10x better than my solo perfectionism would have.

5. Backend developers, understand your frontend. Frontend developers, understand your backend.
I started as a frontend developer. This project forced me to understand backend, APIs, databases, and deployment. That cross-knowledge is what makes you valuable.

Who This Is For

If you are a college student sitting on a half-finished project — finish it. Deploy it. Share it with five real people. Watch what breaks.

You will learn more in one week of real-world usage than in three months of tutorials.

The gap between "I can code" and "I can build things people use" is not talent. It is just willingness to ship, break things, and fix them.

What I Am Building Next

Authentication system with role-based access
Real-time notifications using WebSockets
Mobile-first redesign
Performance improvements for slower connections

Final Thought

Before this project, I used to say: "I am still learning."

Now I say: "I build things people use."

That shift in identity — from student to builder — is worth more than any certificate.

Go build something real.

I am Aswini SM, a 2nd-year ECE student at Panimalar Engineering College, Chennai. I build full-stack web applications and am currently exploring enterprise technologies. You can find my work at https://aswini-sm-portfolio.netlify.app and https://github.com/Aswini1008

[Boost]

Aswini S M — Wed, 25 Jun 2025 16:42:05 +0000

Hanzla Baig

Jun 21 '25

AI Is Slowly Killing Us — And We’re Smiling Through It

#discuss #ai #programming #career

2 min read