DEV Community: Kalpick Sharma

DevRel in 2026: Your Developer Docs Have a New User

Kalpick Sharma — Wed, 02 Sep 2026 15:41:55 +0000

Developer Relations has traditionally been built around one primary audience:

Developers.

We write docs for them.

We build tutorials for them.

We create SDK examples, maintain GitHub repositories, run communities, and answer implementation questions.

But AI coding assistants are changing the developer journey.

The developer may now ask an AI agent to research a library, understand an API, write an integration, or debug an error.

That means your documentation can become an input to an AI agent before it ever reaches a developer.

The new developer journey

Previously:

Developer → Search → Docs → Code

Now:

Developer
↓
AI Assistant
↓
Docs / GitHub / API Reference
↓
AI interprets information
↓
Code
↓
Developer reviews

The developer is still the user.

But the AI can become the first consumer of your developer experience.

That's why documentation quality matters differently now.

Write documentation that removes guessing

Consider this:

Use our SDK for authentication.

It sounds simple, but it leaves a lot unanswered.

A developer or AI agent still needs to figure out:

Which package?
How do I install it?
Where does the API key go?
Can I use it in the browser?
What happens when authentication fails?
What's the response format?

A better example provides actual implementation context:

const client = new Client({
apiKey: process.env.API_KEY
});

const user = await client.users.get("123");

console.log(user);

Then explain what the code does, what the inputs mean, and what can go wrong.

This helps both audiences.

Examples are part of the API

An API reference without good examples can force developers to guess.

AI agents have the same problem.

If the API is:

client.users.create(options)

showing a complete request is more useful:

const user = await client.users.create({
name: "Alex",
email: "alex@example.com"
});

Then document:

Required fields
Optional fields
Response shape
Validation errors
Authentication requirements

The more important the API, the less you want people guessing.

Don't forget errors

Happy-path documentation gets most of the attention.

But debugging is where developers often spend their time.

This:

Request failed.

doesn't give much context.

This is better:

Authentication failed: API_KEY is missing.

Set API_KEY as an environment variable before
creating the client.

Now the developer knows what happened and what to try next.

An AI agent can also map that error to a much clearer action.

Your README matters more than you think

A README should quickly answer:

What is this?
How do I install it?
How do I use it?
What does it support?
What are its limitations?
Where are the detailed docs?

This isn't about adding keywords for AI.

It's about making your project understandable.

That's useful for humans.

It's useful for AI.

And it's useful for maintainers six months later.

The bigger DevRel shift

I don't think DevRel needs to start writing "AI documentation."

Instead, we should improve developer experiences so the information is:

Clear
Structured
Current
Explicit
Easy to retrieve
Easy to implement

AI agents increase the value of these fundamentals.

The interesting change isn't simply that AI can read documentation.

It's that an AI agent can use that documentation while completing a software task.

Read docs
↓
Choose API
↓
Generate code
↓
Run code
↓
Read error
↓
Search docs
↓
Fix code

Documentation becomes part of the development loop.

Final thought

The developer isn't disappearing from DevRel.

The audience is expanding.

Your documentation may now need to work for the developer and the AI assistant helping them.

So instead of asking:

"How do we write docs for AI?"

I'd ask:

"Is our developer experience clear enough for both humans and machines to use correctly?"

That feels like a much better DevRel question for 2026.

Vibe Coding Gets You to Working. Engineering Gets You to Production.

Kalpick Sharma — Tue, 01 Sep 2026 03:05:59 +0000

AI-generated code has changed how quickly I can start a project.

Recently, I used AI while building an Instagram automation bot.

I asked AI to generate the script and function calls.

It worked.

That sounds like the end of the story.

It wasn't.

The First Version Worked

The AI-generated implementation handled the basic workflow.

Functions were being called.

The automation was executing.

The prototype was useful enough to continue building.

But I noticed problems when looking beyond basic execution.

The main areas were API handling, performance, and small implementation mistakes.

There were also some typos.

None of these completely broke the application.

That's exactly why they were interesting.

Working Doesn't Mean Production-Ready

This is probably the biggest lesson I took from the project.

There are several stages between:

"It works"

and

"We should ship this"

For production, I need to think about things like:

API calls
Error handling
Performance
Maintainability
User experience
Edge cases

AI can help with all of these.

But it doesn't mean the generated answer should automatically be trusted.

What I Changed

I didn't throw away the generated implementation.

That would have defeated one of the biggest benefits of using AI.

Instead, I reviewed the areas that mattered.

I changed the API handler.

I fixed typo and implementation errors.

I looked at how the functions were being executed and where the implementation could be improved.

The result was better.

But there was another important realization.

The execution was good, but the overall effect was less than I expected.

That difference is important.

Vibe Coding Is a Starting Point

My current mental model is:

Idea
↓
AI generation
↓
Working prototype
↓
Human review
↓
Refactoring
↓
Testing
↓
Production

Vibe Coding makes the first part much faster.

It doesn't remove the rest.

And as AI gets better at generating code, the review and decision-making stages become even more important.

Why This Matters for Design Engineers

This is where I think the Design Engineer role gets interesting.

A Design Engineer isn't only thinking about whether code works.

They're thinking about whether the implementation makes sense from multiple perspectives.

Does the API flow make sense?

Is the interaction clear?

Is the UI handling failure states?

Is the component maintainable?

Is the implementation unnecessarily expensive?

Does the experience match the user's actual needs?

These questions sit between design and engineering.

AI can generate the implementation.

The Design Engineer needs to shape it.

The Skill Is Changing

I don't think the future of development is simply:

AI writes everything.

It's closer to:

AI writes more of the first version, while developers spend more time reviewing, directing, testing, and improving it.

That means understanding code becomes even more important.

Not because you'll manually write every line.

Because you'll need to recognize when generated code is good, when it's questionable, and when it should never reach production.

That's the difference between generating code and engineering software.

Key Takeaways

• AI is excellent for getting from idea to prototype quickly.

• Working code still needs engineering review.

• API handling and performance can make a big difference even when the basic implementation works.

• The value of developers is shifting toward judgment, architecture, and product thinking.

• Design Engineers can become the bridge between AI-generated implementation and production-quality experiences.

The Death of the Static Web: Designing AI-First Web3 Experiences

Kalpick Sharma — Sun, 30 Aug 2026 11:34:28 +0000

Most websites still work the same way.

Build the interface.

Ship it.

Everyone gets roughly the same experience.

Personalization usually changes a few things based on account settings or user roles.

But Web3 introduces something interesting:

Context.

A wallet can represent a history of interactions, assets, credentials, and protocol activity.

Now combine that with AI.

The interesting question isn't:

Can AI generate a UI?

It can.

The better question is:

Can AI help decide which UI a user actually needs?

From Static to Adaptive

Traditional web:

User → Website → Content

A more context-aware Web3 experience could look like:

User
↓
Wallet / Identity
↓
On-chain Context
↓
AI Interpretation
↓
Adaptive UI

Imagine two people opening the same DeFi dashboard.

A beginner might need education, risk information, and guided actions.

An experienced user might want positions, analytics, and transaction controls immediately.

Why should both users get exactly the same interface?

AI Doesn't Need to Generate Everything

I think this distinction is important.

AI-first UI doesn't have to mean:

Prompt → Generate Entire Website

A more controlled approach is:

Context
↓
AI
↓
Structured Decision
↓
React Components

For example:

{
"experience": "advanced",
"components": [
"portfolio",
"activity",
"execution"
]
}

The frontend can then decide what is actually allowed to render.

function Dashboard({ experience }) {
return (
<>
{experience.components.includes("portfolio") && (

)}

  {experience.components.includes("activity") && (
    <ActivityFeed />
  )}

  {experience.components.includes("execution") && (
    <TransactionPanel />
  )}
</>

);
}

AI decides what might be relevant.

The application decides what is safe.

That's a much better boundary.

The UX Problem

Adaptive interfaces create another challenge:

Trust.

If the UI changes without explanation, users may wonder what happened.

So the experience needs things like:

• Clear reasoning
• User control
• Predictable states
• Fallback experiences
• Permission boundaries

Especially for applications handling money or transactions.

Designing Components Differently

As a designer and frontend developer, this changes one question for me.

Traditional question:

What should this component look like?

AI-first question:

When should this component exist?

That's a bigger design problem.

You're not only designing screens anymore.

You're designing possible states.

Component Library
↓
Experience States
↓
Context
↓
AI Decision
↓
Runtime Composition
The New Design System

A traditional design system contains things like:

Typography
Colors
Spacing
Components
Patterns

An adaptive system may also need:

Context
Permissions
States
Rules
AI boundaries
Fallbacks

The component library becomes the vocabulary.

AI helps choose from that vocabulary.

Humans still define the grammar.

Don't Let AI Become the Source of Truth

For Web3 applications, I'd keep the architecture separated:

Blockchain
↓
Source of Truth

Application
↓
Business Rules

AI
↓
Interpretation

UI
↓
Presentation

This makes the system easier to test and reason about.

The AI can recommend or interpret.

It shouldn't silently redefine authoritative state.

The Web Isn't Going Away

I don't think the future means every website becomes an AI-generated interface.

That would create plenty of problems.

Instead, I think we're moving toward interfaces that are more aware of context.

The same product could provide different experiences based on:

Identity
+
Intent
+
History
+
Permissions
+
Context

The UI doesn't need to be completely generated.

It just needs to become less static.

As someone working across UI/UX and frontend development, that's the part I'm watching closely.

The interesting future isn't AI replacing the interface.

It's AI helping the interface understand what matters right now.

Key Takeaways

• Web3 can provide applications with richer user context through on-chain activity and identity.

• AI can interpret that context without needing to generate the entire interface.

• Designers may increasingly design systems of possible experiences instead of only static screens.

• Frontend architecture needs clear boundaries between AI decisions and actual UI behavior.

• Adaptive interfaces need transparency and user control to maintain trust.

• The goal isn't a fully AI-generated web. It's a web that can adapt within human-designed boundaries.

AI Didn't Change My Design Process. It Changed How I Start It.

Kalpick Sharma — Tue, 04 Aug 2026 19:53:00 +0000

Every designer knows the feeling.

You open Figma.

You stare at an empty canvas.

You spend the next thirty minutes deciding where to begin.

That's the part AI quietly improved for me.

Starting With Ideas Instead of Nothing

Instead of manually creating the first wireframe, I now use AI to generate multiple layout directions.

I don't copy them.

I compare them.

Sometimes all five are wrong.

Sometimes one contains an interaction pattern I hadn't considered.

That's already valuable.

AI Is an Exploration Tool

I don't think AI is replacing design thinking.

It's replacing repetitive setup work.

That lets me focus on:

User flows
Accessibility
Product goals
Edge cases
Collaboration

Those are the parts users actually notice.

One Habit I've Started

Before sending designs to developers, I ask AI to review them.

Questions like:

Is hierarchy obvious?
Which accessibility issues stand out?
Are components consistent?
Is anything confusing?

It doesn't replace human reviews.

It improves the first draft of feedback.

Final Thoughts

The best thing AI gave me wasn't a generated interface.

It was a better place to begin.

Instead of fighting the blank canvas, I spend more time refining ideas.

For me, that's where AI creates the most practical value.

Key Takeaways
AI changes the starting point of design, not the quality of design thinking.
Generative UI is most valuable during exploration, not decision-making.
Designers still own research, UX, accessibility, and product trade-offs.
AI can serve as a lightweight design reviewer before team feedback.
Better AI-assisted design workflows lead to smoother frontend implementation.

Human-Centered AI Design Patterns Every Developer Should Know

Kalpick Sharma — Thu, 23 Jul 2026 07:51:33 +0000

When I first started building with AI APIs, I thought my job ended once the model returned a response.

It turns out that's where the real work begins.

Users don't experience prompts or APIs.

They experience interfaces.

That idea led me to explore Human-Centered AI Design Patterns.

AI Is Different from Traditional Software

Traditional applications produce predictable outputs.

AI produces predictions.

That changes how we design products.

Interfaces now need to answer questions like:

Can I trust this?
Why did the AI recommend it?
Can I undo this action?
Should I verify the result?
Four Design Patterns Worth Learning
Confidence Indicators

Help users understand how reliable a response might be.

Confidence: High
Explainability

Give users a simple explanation instead of asking them to blindly trust the AI.

Why this recommendation?

• Based on project history
• Similar previous requests
Undo AI Actions

AI should encourage experimentation.

Giving users an undo option makes AI feel much safer.

Progressive Disclosure

Keep the interface simple.

Reveal reasoning, sources, or technical details only when users request them.

What Changed My Thinking

Earlier, I focused on models.

Now I'm spending more time thinking about interactions.

Because users rarely remember which AI model powered a feature.

They remember whether the experience felt understandable and under their control.

That's what Human-Centered AI Design Patterns are really about.

Key Takeaways

AI interfaces should communicate uncertainty instead of hiding it.
Confidence indicators help users decide when to trust AI outputs.
Explainability improves transparency without overwhelming users.
Undo actions make AI feel safer and encourage experimentation.
Progressive disclosure keeps interfaces simple while supporting advanced users.
Great AI products combine strong models with thoughtful interaction design.

Community-Led Growth: The Growth Strategy Every Developer Tool Should Understand

Kalpick Sharma — Wed, 22 Jul 2026 14:13:02 +0000

Most developer tools don't become popular because of advertising.

They grow because developers trust them.

That trust usually comes from things like:

Great documentation
Helpful maintainers
Active open source contributors
Friendly communities

As I spent more time around open source and communities like AlloyTrik, I realized something interesting.

Community isn't separate from the product.

It is part of the product experience.

Developers Notice Small Things

When trying a new tool, I usually look for:

Clear setup instructions
Recent commits
Active issue discussions
Helpful Discord or GitHub conversations

These signals tell me whether the project is alive.

Documentation Is an Investment

Every well-written guide saves maintainers from answering the same question repeatedly.

It also helps new developers become productive faster.

That's a growth strategy, not just documentation.

Community Creates Contributors

The best communities make beginners feel comfortable asking questions.

Eventually those beginners become contributors.

Then maintainers.

Then advocates.

That's a much stronger growth loop than paid acquisition.

*My Biggest Takeaway
*
Helping one developer may seem small.

But hundreds of small interactions create something much larger.

Community-led growth isn't fast.

It's consistent.

And over time, consistency becomes trust.

For developer tools, that's one of the hardest advantages to replicate.

flowchart TD
A[Developer discovers tool]
B[Reads documentation]
C[Joins community]
D[Gets help]
E[Builds project]
F[Contributes back]
G[Helps new developers]

A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> C

Key Takeaways

Community is a long-term growth strategy, not just a support channel.
Developers trust people more than advertisements.
Documentation is part of the developer experience.
Open source encourages transparency and contribution.
Helpful maintainers often become the strongest marketing channel.
Small interactions compound into long-term adoption.
Community-led growth creates durable competitive advantages because trust is difficult to copy.

Open Source AI Models Are Closing the Gap. Why That Matters for Developers

Kalpick Sharma — Tue, 14 Jul 2026 08:22:09 +0000

When I first started exploring AI, it felt like the only serious option was using proprietary APIs.

Now that picture looks very different.

Models like Llama, Mistral, and Qwen have improved quickly. While proprietary models still lead in many areas, open-weight models are becoming practical for real applications.

For developers, that changes how we learn and build.

Why Open Models Are Growing

Three reasons stand out:

Lower costs for production workloads
More control over data and deployment
Freedom to customize models for specific tasks

These aren't just enterprise concerns. They're useful for individual developers too.

Learning AI Is Becoming More Accessible

Instead of worrying about API usage, you can experiment locally.

That means:

Testing prompts
Building prototypes
Understanding model behavior
Exploring AI workflows

The barrier to entry is much lower than it was a year ago.

The Bigger Lesson

Choosing a model isn't the whole application.

Modern AI products depend on:

Context
Retrieval
Tool calling
Evaluation
Good UX

That's where many engineering challenges actually live.

Closing Thoughts

Open models aren't replacing proprietary ones overnight.

But they are giving developers more freedom to choose the right tool for each project.

The exciting part isn't that one model wins.

It's that more people can build AI without depending on a single provider.

Key Takeaways
Open models are improving quickly.
Learning AI is becoming cheaper and more accessible.
Model orchestration is becoming more important than model access.
Developers should focus on building complete AI systems, not only comparing benchmarks.

Your Loading Spinner Has an Emotional Job. Is It Doing It?

Kalpick Sharma — Fri, 10 Jul 2026 21:23:57 +0000

Most of us treat design systems as a functional problem: consistent colors, consistent spacing, consistent components. That part's solved for most teams now.

The part nobody writes down is tone. How should this loading state feel? Should this error feel scary or manageable? Is this confirmation message robotic or human?

Here's what I've learned paying attention to that layer.

Four moments that carry the emotional weight

In any app, four states do most of the emotional work:
Loading
Error
Empty
Success

Get these four right and the whole product feels better, even if nothing about the actual functionality changed.
**
Loading: ambiguity feels worse than the wait itself**

jsx// Vague, slightly anxious
<Spinner />

// Specific, calmer
<div className="loading-state">
  <Spinner />
  <p>Fetching your latest data...</p>
</div>

A spinner with no context makes people wonder if something's frozen. A spinner with a short label tells them exactly what's happening. Same wait time, different feeling.

Errors: same bug, different emotional outcome

jsx// Robotic
"Error: Request failed with status 500"

// Human
"Something went wrong on our end. Your changes weren't lost, try again in a moment."

The second version does three things the first doesn't: it's plain language, it removes blame from the user, and it tells them what to do next. That's the difference between an error that frustrates and one that reassures.

Success: robotic vs genuine

jsx// Robotic
"Action completed successfully."

// Human
"Done! Your changes are saved."

This message shows up constantly across a typical app. If it reads like a system log every time, the product feels cold. A small rewrite makes it feel like a person is on the other end.

Micro-interactions: timing is part of tone too

`jsx// No feedback during the wait, feels broken
<button onClick={handleSave}>Save</button>

// Immediate feedback, feels responsive
<button onClick={handleSave}>
  {isSaving ? "Saving..." : "Save"}
</button>`

A button that responds instantly feels trustworthy. One with an unexplained delay feels buggy, even if it technically worked. Users feel latency even when they can't see it.

A simple way to start

Write a small tone map for your product. Nothing fancy, just enough to keep everyone on the same page:

jsconst toneMap = { loading: { feeling: "calm", copyStyle: "specific, low-pressure" }, error: { feeling: "reassuring", copyStyle: "plain language, offer next step" }, success: { feeling: "genuine delight", copyStyle: "short, warm, specific" }, };

Check new copy and motion against this before shipping. It's a small habit that compounds into a product that actually feels good to use, not just one that works.

** Key Takeaways**

Functional design (it works) is no longer enough. Emotional resonance (how it feels) is the next differentiator.
Four moments carry most of the emotional weight in any product: loading, error, empty, and success states.
Small copy changes (robotic vs human language) change emotional outcomes without changing functionality.
Timing and motion are part of the emotional system too. Users feel latency even when they don't see it.
Build a simple "tone map" the same way you'd build a design token system, so tone stays consistent across the team instead of being left to individual taste.

Trust Architecture in AI Products

Kalpick Sharma — Mon, 06 Jul 2026 20:41:31 +0000

When I first started exploring AI products, I focused on prompts, models, and response quality.

Recently, I came across another concept that feels just as important.

Trust Architecture.

I'm still learning about it, but here's my understanding from a developer's perspective.

What is Trust Architecture?

Trust Architecture is the collection of product, design, and engineering decisions that help users trust an AI system.

It's less about making AI smarter and more about making its behavior understandable.

Users should know:

Where information came from
When AI is uncertain
How to verify answers
What AI can and can't do
Why It Matters

Unlike traditional software, AI isn't always deterministic.

It can produce different responses to similar prompts.

That means users need signals that help them judge the reliability of the output.

Practical Ideas

If you're building AI features, consider adding:

Source references
Confidence indicators
Human review options
Clear AI labels
Feedback mechanisms

These small additions can make a big difference in user confidence.

Example

Instead of only showing an AI-generated answer, display something like:

Generated using:
✓ Official Documentation
✓ Internal Knowledge Base

Confidence: High

Now users have more context before acting on the response.

Final Thoughts

My biggest takeaway so far is simple.

AI products shouldn't only optimize for intelligence.

They should also optimize for trust.

I'm still exploring this topic, and I'd love to hear how others think about building trustworthy AI experiences.

Key Takeaways

AI intelligence and user trust are different problems.
Trust Architecture combines UX, engineering, and product decisions.
Transparency often matters as much as correctness.
Showing sources and uncertainty can increase user confidence.
Trust should be considered from the first version of an AI product, not added later. What you think??Drop in comments

AI-Powered Design Systems: The Part Nobody Talks About

Kalpick Sharma — Sun, 05 Jul 2026 19:47:56 +0000

Whenever AI and design are mentioned together, the conversation usually focuses on generating interfaces.

But after working across both design and frontend development, I think the more interesting opportunity is somewhere else.

Maintaining design systems.

As products grow, so do their component libraries, documentation, design tokens, accessibility requirements, and implementation details.

Keeping everything consistent becomes harder than building it in the first place.

That's where AI can make a real difference.

Some practical ways AI can support design systems include:

Detecting duplicate components
Suggesting existing patterns before creating new ones
Generating component documentation
Auditing accessibility issues
Keeping design tokens synchronized
Helping new developers understand the system faster

None of these replace designers or developers.

Instead, they remove repetitive maintenance work that often slows teams down.

Imagine asking:

Do we already have a component for this?

Or:

Why is this button different from the design system?

An AI assistant could answer instantly by understanding both the design library and the codebase.

That's a much more practical use of AI than simply generating another landing page.

Closing Thoughts

AI-powered design systems aren't just about creating UI faster.

They're about helping teams maintain consistency, improve collaboration, and spend more time solving real product problems.

That's the future I'm excited to see.

Agentic Software Development Explained: A Frontend Developer's Learning Journey

Kalpick Sharma — Sat, 04 Jul 2026 23:23:33 +0000

For the last couple of years, AI has become a regular part of my development workflow.

Whether it's debugging a React component, generating boilerplate code, or explaining an unfamiliar concept, AI has saved me a lot of time. Like many developers, I treated it as an assistant that responds to prompts.

Recently, I started noticing a new term appearing in articles, conference talks, and developer discussions:

Agentic Software Development and Now Looping.

At first, I assumed it was just another AI buzzword.

After spending some time reading about it, I realized it's actually describing a different way of building software.

This article isn't written from the perspective of an AI expert. It's my attempt to understand the concept as a frontend developer and explain it in a simple way.

The Way We Use AI Today

Most developers interact with AI like this:

Ask a question.
Get an answer.
Review the output.
Ask another question.

For example:

"Create a React component."
"Explain this error."
"Write unit tests."
"Optimize this function."

Every interaction starts with a new prompt.

AI is helpful, but it waits for us to decide what happens next.

So What's Changing?

Instead of asking AI to complete one task at a time, imagine giving it a goal.

Instead of saying:

Build a login page.

You could say:

Build the complete authentication feature for my application.

Rather than stopping after generating a response, an AI agent can:

Plan the work.
Break it into smaller tasks.
Generate code.
Run tests.
Review results.
Fix problems.
Continue until the objective is complete.

That's the core idea behind Agentic Software Development.

Understanding the Agent Loop

One idea that made this concept easier for me to understand is the execution loop.

Traditional AI looks something like this:

Developer
↓
Prompt
↓
AI Response
↓
Next Prompt

An AI agent follows a continuous cycle:

Goal
↓
Plan
↓
Execute
↓
Evaluate
↓
Improve
↓
Repeat

Instead of waiting after every response, the agent evaluates its own progress and decides the next action until the objective is achieved.

Why This Matters

I don't think AI agents replace developers.

Instead, I think they'll change where we spend our time.

Developers still need to:

Understand requirements.
Design system architecture.
Review generated code.
Make technical decisions.
Ensure security, accessibility, and performance.

AI may automate implementation, but developers remain responsible for delivering the right solution.

My Frontend Perspective

As someone building React applications and internal tools, I can already imagine AI agents helping with repetitive work like:

Setting up project structure.
Creating reusable components.
Connecting APIs.
Writing tests.
Refactoring repetitive code.
Updating documentation.

That gives me more time to focus on product thinking, user experience, and performance optimization.

My Biggest Takeaway

Before learning about AI agents, I thought the future of AI was writing better code.

Now I think the bigger shift is helping developers complete entire software tasks.

That's a subtle difference, but an important one.

We're gradually moving from asking AI for answers to giving AI objectives.

Final Thoughts

I'm still learning about Agentic Software Development, and this article reflects my current understanding as a frontend developer.

Technology will continue to evolve, but one thing hasn't changed:

Good engineering is still about solving problems, making thoughtful decisions, and building software that helps people.

AI agents may change how we build software, but they don't replace the need for developers who understand the bigger picture.

If you're exploring Agentic Software Development too, I'd love to hear your thoughts.

How do you think AI agents will fit into your workflow?

Building a Lightweight PWA Meeting App with Vanilla JavaScript and WebRTC

Kalpick Sharma — Fri, 03 Jul 2026 22:09:14 +0000

I recently built a small meeting application for our community's internal discussions.

The goal wasn't to replace Google Meet or Zoom.

It was to build something lightweight that solved exactly what we needed.

Stack
HTML
CSS
JavaScript
WebRTC
Progressive Web App
Render for hosting
Why Vanilla JavaScript?

I wanted to understand WebRTC without a framework hiding the implementation details.

Working directly with browser APIs made debugging easier and helped me understand peer connections much better.

Why Mesh Topology?

Our meetings usually have only a few participants.

A mesh network lets every participant connect directly to everyone else, which keeps the architecture simple for small groups.

Features
Peer-to-peer video calls
Audio mute and unmute
Background changer
Installable as a PWA
Responsive interface
Biggest Takeaway

Building real tools teaches concepts much faster than tutorials.

This project helped me understand WebRTC, media streams, browser APIs, and Progressive Web Apps while creating something our community could actually use.

If you're learning WebRTC, I'd recommend building a small internal tool before trying to create a full video conferencing platform.
General Meet Prototype