DEV Community: Pratik Dhore

The Psychology of Technical Debt

Pratik Dhore — Mon, 27 Jul 2026 14:30:00 +0000

Ask any developer if technical debt is a good thing.

Almost everyone will say:

"No."

Then ask them another question.

"Have you ever knowingly introduced technical debt?"

Almost everyone will say:

"Yes."

I've always found that fascinating.

We're all aware of technical debt.

We know it slows projects down.

We know it makes bugs harder to fix.

We know future developers—including our future selves—will probably hate it.

And yet...

We still do it.

Not because we're careless.

Not because we're bad developers.

But because software development is rarely about making perfect decisions.

It's about making the best decision with the information and constraints we have today.

Technical Debt Isn't Usually an Engineering Problem

When people talk about technical debt, they often describe code.

Messy functions.

Duplicate logic.

Huge classes.

Poor architecture.

But I've started to think technical debt has much less to do with code than it does with psychology.

The code is just where the decisions become visible.

The real causes are usually things like:

Deadlines
Uncertainty
Fear of breaking working code
Limited information
Business priorities
Optimism

Those are human problems.

Not technical ones.

"We'll Clean It Up Later"

I think every developer has said this at least once.

"Let's just get this working first."

Sometimes that's exactly the right decision.

Shipping matters.

Customers matter.

Deadlines matter.

The problem is that "later" rarely arrives.

A shortcut taken during a two-hour sprint quietly becomes part of the system for the next three years.

Not because nobody cared.

Because everyone was busy solving the next urgent problem.

The Fear of Touching Working Code

One of the biggest sources of technical debt isn't writing bad code.

It's avoiding code that already works.

We've all experienced it.

You open a file.

It's 2,500 lines long.

Nobody on the team originally wrote it.

There are no tests.

The last person who understood it left the company.

Everything inside feels interconnected.

You make one tiny change...

...and suddenly you're wondering if you've broken six unrelated features.

So what happens?

You don't refactor.

You work around it.

Then someone else works around your workaround.

And eventually everyone agrees that the file is "too risky to touch."

Technical debt grows because fear compounds over time.

Success Can Create Technical Debt

This one surprised me.

We often assume technical debt comes from failure.

In reality, it often comes from success.

Imagine building a feature that's expected to be used for six months.

You optimise for speed.

Simple architecture.

Minimal abstraction.

Reasonable shortcuts.

Then the feature becomes incredibly popular.

Three years later it's one of the most important parts of the application.

The shortcuts are still there.

The temporary solution became permanent because the product succeeded beyond expectations.

Sometimes technical debt is simply yesterday's sensible decision.

Every Shortcut Has Compound Interest

Financial debt grows because of interest.

Technical debt works the same way.

At first it's barely noticeable.

Adding a new feature takes an afternoon.

A few months later it takes two days.

Eventually simple changes require multiple developers, several meetings, and a full regression test.

The code didn't suddenly become bad.

It became expensive to change.

That's the real cost of technical debt.

Not ugly code.

Reduced velocity.

Perfection Is Also Expensive

Here's something I wish I'd understood earlier.

Not every shortcut is bad.

And not every refactor is worth doing.

I've seen developers spend weeks creating the "perfect" architecture for a feature that might never need to scale.

That's a different kind of waste.

The goal isn't eliminating technical debt.

That's impossible.

The goal is choosing which debt is worth taking on.

Just like financial debt, some investments make sense.

Others don't.

Good Teams Talk About Debt

One thing I've noticed on stronger engineering teams is that technical debt isn't ignored.

It's discussed openly.

Not as blame.

Not as failure.

As a conscious trade-off.

Sometimes the conversation sounds like this:

"We're taking this shortcut because we need to ship this release."

The important part comes next.

"Let's create a ticket to revisit this after launch."

Will every piece of debt get paid back?

Probably not.

But acknowledging it is much healthier than pretending it doesn't exist.

My Biggest Lesson

The longer I work in software, the less I think technical debt is about code quality.

It's about decision-making.

Every line of code represents a trade-off between time, complexity, risk, and value.

Sometimes the right decision is the elegant solution.

Sometimes it's the quickest one.

The important thing is understanding why you're making that decision.

Because technical debt isn't dangerous when it's intentional.

It's dangerous when everyone forgets it exists.

Final Thoughts

I don't think we'll ever eliminate technical debt.

And honestly, I don't think we should try.

Software evolves.

Requirements change.

Deadlines exist.

Business priorities shift.

Technical debt is simply part of building products.

The challenge isn't avoiding it.

The challenge is making sure today's shortcut doesn't quietly become tomorrow's biggest obstacle.

I'd love to hear your thoughts.

What's the biggest piece of technical debt you've inherited—or accidentally created?

Sometimes those stories teach us more than any architecture diagram ever could.

Thanks for reading! If this resonated with you, I'd love to hear how your team approaches technical debt. Every project has it—the interesting part is how we choose to live with it.

programming #softwareengineering #career #productivity

Angular Isn't Slow. Your Architecture Is.

Pratik Dhore — Sun, 26 Jul 2026 11:06:25 +0000

Angular Isn't Slow. Your Architecture Is.

Every few months, I come across a post saying:

"Angular is slow."

Honestly, I used to believe there was at least some truth to it.

Over the last few weeks, I spent a significant amount of time migrating a fairly large enterprise application from Angular 16 to Angular 21. Like most migrations, I expected dependency conflicts, build issues, and a few breaking changes.

I got all of those.

What I didn't expect was to question how I write Angular applications.

The migration made me realize something that I hadn't thought about before:

Angular isn't slow anymore.

Most of us are simply writing Angular 21 applications using patterns that were perfectly reasonable five or six years ago.

The framework has evolved much faster than many of our codebases.

Angular Has Changed More Than You Think

If the last Angular version you seriously explored was Angular 10 or 11, modern Angular might surprise you.

Today we have:

✅ Standalone Components
✅ Signals
✅ New template control flow (@if, @for, @switch)
✅ Deferred loading
✅ Faster builds with esbuild
✅ Better SSR and hydration
✅ Zoneless applications
✅ Functional dependency injection using inject()

These aren't just quality-of-life improvements.

They fundamentally change how applications can be structured.

The problem is that many teams upgrade Angular every six months, but their architecture stays exactly the same.

The Framework Gets Blamed for Problems It Didn't Create

Whenever I hear someone say Angular is slow, I usually ask one question:

"What exactly is slow?"

Most of the time, the answers sound familiar.

Initial page load
Long build times
Components taking forever to render
UI freezing
Huge bundle sizes

Those are real problems.

But after looking at enough enterprise applications, I've noticed they rarely come from Angular itself.

Instead, they usually come from things like:

Components with thousands of lines of code
Massive SharedModules importing everything
Every feature loading on startup
Too many unnecessary RxJS subscriptions
Heavy third-party libraries
Business logic living inside components
Poor change detection strategies

Those problems would exist regardless of the framework.

Stop Writing Angular 21 Like It's Angular 10

One thing I noticed during migration was how many old habits I had carried forward simply because "that's how Angular projects are built."

It turns out many of those habits are no longer the recommended approach.

Standalone Components

When Standalone Components were first introduced, I thought they were just another way to avoid NgModules.

After using them throughout a migration, I completely changed my opinion.

Each component clearly declares what it depends on.

Features become easier to lazy load.

There's less boilerplate.

And perhaps most importantly, navigating the project becomes much easier.

Instead of jumping through multiple modules trying to understand where something is declared, everything is right where you'd expect it.

Small improvement.

Huge quality-of-life difference.

Signals Changed How I Think About State

For years, my default approach looked something like this:

Need reactive data? Create another Observable.

Now I find myself asking a different question.

Does this actually need to be an Observable?

A surprising amount of component state doesn't.

Loading indicators.

Selected items.

Counters.

Filters.

Simple UI state.

Signals handle these incredibly well while keeping components much easier to understand.

I'm definitely not saying RxJS is obsolete.

Far from it.

It's still the right tool for asynchronous streams, HTTP requests, websockets, and complex event flows.

But using RxJS for every piece of state now feels a bit like using a sledgehammer to hang a picture frame.

The New Template Syntax Is Better Than I Expected

I'll admit it.

When Angular announced the new control flow syntax, I didn't think it would make much difference.

I was wrong.

Instead of writing:

<div *ngIf="users.length">
  <app-user-card
    *ngFor="let user of users; trackBy: trackById"
    [user]="user">
  </app-user-card>
</div>

We can now write:

@if (users.length) {
  @for (user of users; track user.id) {
    <app-user-card [user]="user" />
  }
}

It feels cleaner.

It's easier to read.

And because track becomes part of the syntax, it's easier to write performant lists by default.

Build Speed Matters More Than We Admit

One of my favourite improvements had nothing to do with runtime performance.

It was the build process.

Moving to Angular's modern build system with esbuild made local development noticeably faster.

The interesting thing about faster builds isn't just saving a few seconds.

When builds are quicker:

You experiment more.
You refactor more confidently.
You test ideas more often.
You spend less time waiting.

Developer experience matters.

Over hundreds of builds each month, those small improvements add up.

Performance Isn't Just About Rendering

When developers say an application is slow, they're usually describing the entire experience.

Questions like:

How quickly does the application start?
How responsive does the UI feel?
How long do builds take?
How much JavaScript are users downloading?
How much code executes before the first interaction?

Angular 21 improves many of these areas.

But if we're still shipping huge bundles, importing entire libraries for one utility function, or putting thousands of lines of business logic into a single component, the framework can't solve those problems for us.

Architecture still matters.

Things I'd Review in Any Angular Project Today

If I joined a new Angular project tomorrow, these are some of the first things I'd look at.

Are we still relying on huge SharedModules?
Could some component state become Signals instead of Observables?
Are routes properly lazy loaded?
Are components trying to do too much?
Are we importing libraries we barely use?
Are we using track with @for?
Are Standalone Components being used consistently?
Can features be split into smaller, independent pieces?

None of these changes are revolutionary.

But together they make projects easier to maintain, easier to scale, and often noticeably faster.

My Biggest Takeaway

The biggest lesson from this migration wasn't learning a new Angular feature.

It was realizing how easy it is to upgrade the framework without upgrading our thinking.

Installing Angular 21 takes a few commands.

Writing applications that actually take advantage of Angular 21 takes a different mindset.

Sometimes the biggest performance improvement isn't a new API.

It's letting go of patterns we've been carrying around for years.

Final Thoughts

Angular has evolved a lot.

The tooling is faster.

The APIs are cleaner.

The developer experience is better than it's ever been.

The question isn't whether Angular is fast enough anymore.

The better question is:

Are we building applications that take advantage of what modern Angular offers?

I'd genuinely love to hear what others think.

If you've migrated to Angular 20 or 21 recently, what architectural change made the biggest difference in your project?

Thanks for reading! If you enjoyed this article or have a different perspective, let's discuss it in the comments. I always enjoy hearing how other teams are approaching modern Angular.

angular #webdev #performance #javascript

Some Bugs Aren't in Your Code. They're Hidden in Your Dependencies.

Pratik Dhore — Mon, 20 Jul 2026 16:35:46 +0000

This is my second submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

As developers, we've all heard it before:

"It works on my machine."

In my case, it was even stranger.

It worked perfectly on one set of development VMs.

It consistently failed on another.

Same codebase.
Same branch.
Same application version.

Different behavior.

At first glance, it looked like an environment issue. But what started as a simple investigation turned into one of the most interesting debugging sessions I've had—and it taught me an important lesson about trusting assumptions.

The Mystery

A few developers on our team started reporting inconsistent behavior while testing the same feature.

Developers working on one group of VMs couldn't reproduce the issue.

Developers using another group of VMs could reproduce it every single time.

Naturally, we started comparing everything.

Were we using different builds?
Different configuration files?
Different database versions?
Different operating system patches?
Different .NET runtimes?

Nothing stood out.

The environments were supposed to be identical.

Chasing the Wrong Suspects

When a bug only appears in one environment, it's tempting to blame infrastructure.

We spent hours checking VM configurations, network settings, installed software, and deployment differences.

Every comparison ended with the same conclusion:

Everything looked correct.

The more we investigated, the less the infrastructure looked guilty.

So we changed our approach.

Instead of asking:

"What's different about these VMs?"

We started asking:

"What exactly happens between sending a request and receiving a response?"

That shifted our attention from the environment to the application's HTTP layer.

Looking Beyond Business Logic

We started comparing requests and responses generated from both environments.

Headers looked normal.

Payloads looked normal.

The API wasn't returning errors.

Business logic wasn't failing.

At first, nothing explained why identical requests were producing different behavior.

Then we started looking at something nobody had questioned:

The HTTP client itself.

Our project was still using an older version of RestSharp.

Digging deeper revealed something interesting.

Older versions of RestSharp relied on SimpleJson as their built-in serializer.

That wasn't something we'd consciously chosen—it had simply existed in the project for years.

Until now, nobody had questioned it.

The Hidden Dependency

The breakthrough came when we focused on serialization instead of infrastructure.

Serialization sits in an awkward place in an application.

You rarely think about it.

You trust it to convert objects into JSON and JSON back into objects.

When it works, it's invisible.

When it doesn't...

Nothing makes sense.

The issue wasn't our business logic.

It wasn't the API.

It wasn't the database.

It was a legacy serialization layer quietly sitting underneath everything.

While researching the dependency, we discovered that this wasn't unique to our project.

When RestSharp introduced version 107, the maintainers removed SimpleJson completely and migrated to System.Text.Json, citing legacy architecture and serialization quirks as reasons for the redesign.

That discovery completely changed how we looked at the problem.

Instead of trying to patch symptoms, we focused on eliminating the outdated dependency.

The Fix

Rather than adding workarounds around the failing behavior, we updated our serialization approach by moving away from the older RestSharp implementation that depended on SimpleJson.

After validating the changes across both VM environments, the inconsistent behavior disappeared.

The application behaved the same everywhere.

Not because we changed our business logic.

Not because we reconfigured the VMs.

But because we removed a piece of technical debt that had quietly become part of the application's foundation.

What This Bug Taught Me

This incident completely changed the way I investigate environment-specific issues.

When code behaves differently across environments, it's easy to blame the environment itself.

Sometimes that's true.

But sometimes the real culprit is hidden several layers beneath your own code.

A dependency you haven't updated in years.

A serializer you didn't even know your project was using.

A library that everyone forgot existed because it "just worked."

Until it didn't.

Takeaways

Don't stop at your own code—inspect the libraries underneath it.
Environment-specific bugs aren't always infrastructure bugs.
Legacy dependencies can introduce behavior that's incredibly difficult to diagnose.
If a dependency has been completely redesigned by its maintainers, it's worth understanding why.

The biggest lesson from this bug wasn't about RestSharp.

It was about curiosity.

The answer wasn't in our application code.

It was hiding inside a dependency that most of us had never looked at.

Sometimes, the hardest bugs aren't the ones you wrote.

They're the ones you've been shipping for years without even realizing it.

restsharp #dotnet #api-development #serializer #deserializer

Enterprise Development Isn't Hard Because of Code

Pratik Dhore — Sun, 19 Jul 2026 11:29:40 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

When I first started my career as a software engineer, I believed the hardest part of the job would be writing complex code.

I imagined solving difficult algorithms, implementing challenging features, and fixing obscure bugs buried deep inside thousands of lines of code.

But after working on a large enterprise application, I've realized something very different.

Enterprise development isn't hard because of the code.

It's hard because of everything connected to the code.

It Started With "Just an Angular Upgrade"

A few weeks ago, I was asked to assess what it would take to migrate one of our enterprise Angular applications to a newer version.
My first thought was simple.

"Update Angular, fix a few compilation errors, run the tests, and we're done."

If you've ever worked on a side project or a small application, that's usually how it goes.

But enterprise software doesn't work that way.

Within the first hour, I realized I wasn't looking at an Angular upgrade anymore.

I was looking at an ecosystem.

Every Answer Led to Three More Questions

Updating Angular wasn't the real challenge.

The real challenge was understanding everything that depended on Angular.

Questions started appearing one after another.

Is our UI component library compatible?
What about Angular Material?
Will our build tools still work?
Does our Node.js version meet the new requirements?
Are all third-party libraries still maintained?
Will our Docker builds continue to succeed?
Will the CI pipeline require changes?
Are there multiple applications sharing the same workspace?

Every answer uncovered another dependency.

Instead of updating packages, I spent most of my time mapping relationships between technologies.

And honestly...
That was the right thing to do.

The Biggest Surprise

At one point, I realized I had spent almost an entire afternoon without writing a single line of code.

Normally, that would feel unproductive.

This time, it wasn't.

By understanding the system first, I was preventing problems that could have taken days to debug later.

I wasn't writing code.

I was reducing risk.

That was the moment my perspective on software engineering changed.

Enterprise Software Is a Web of Dependencies

In smaller projects, changing a package version usually affects only your application.

In enterprise software, a single version upgrade can affect:

Internal shared libraries
Build tools
Deployment pipelines
Docker images
CI/CD workflows
Authentication systems
Shared components
Multiple development teams

Every dependency has its own lifecycle.

Every change has a ripple effect.

Sometimes the code you're changing is actually the easiest part.

Understanding the consequences of that change is where the real challenge begins.

The Lesson I Didn't Expect to Learn

When I was a junior developer, I measured progress by the number of lines of code I wrote.

Today, I measure progress differently.

Sometimes the most valuable thing you can do is:

Read documentation.
Trace dependencies.
Understand the architecture.
Ask the right questions.
Identify risks before touching the code.

None of these activities produce immediate results.

But they prevent future problems.

And that's what good engineering looks like.

It's Not About Being the Fastest Coder

One thing I've learned after working on enterprise applications is that the best engineers aren't necessarily the fastest programmers.

They're the people who understand the system.

They know which component depends on another.

They know why a seemingly harmless package update can break a deployment pipeline.

They know when not to change something.

Most importantly, they understand that software isn't just code.

It's people, processes, tools, infrastructure, history, and countless decisions made over many years.

Final Thoughts

If someone asked me today what makes enterprise software difficult, my answer would be very different from what it was.

It isn't the complexity of the code.

It's the complexity of the ecosystem surrounding it.

The next time you're asked to make what sounds like a "simple upgrade," take a step back before opening your editor.

Understand the system first.

Because in enterprise development, changing one line of code is often easy.

I'd love to hear from other developers:

What's one task that sounded simple at first but turned out to reveal the hidden complexity of an enterprise system? Share your story in the comments!

bugsmash #webdev #programming #angular #career

Understanding everything that line touches is the real challenge.

7 Things Nobody Tells You Before Deploying Your First Full-Stack Application

Pratik Dhore — Fri, 17 Jul 2026 17:36:40 +0000

When I built my first full-stack application, I thought the hard part was writing the code.

I was wrong.

The application worked perfectly on my local machine. The frontend loaded, the backend responded, the database connected, and everything seemed ready for production.

Then I deployed it.

That's when I realized deployment isn't just the final step—it's an entirely different skill.

Here are seven lessons I learned while deploying my projects.

"It Works on My Machine" Doesn't Mean Anything

Your local environment is comfortable because everything is already configured.

Production is not.

Different operating systems, missing environment variables, different file paths, and networking rules can expose issues you never noticed during development.

Before assuming your code is broken, compare the environments.

Logs Are Your Best Friend

When something goes wrong, don't immediately start changing code.

Read the logs.

Whether you're using Docker, ASP.NET, Flask, or Node.js, logs usually tell you where to start looking.

Many hours of debugging can be saved by reading the first meaningful error instead of the last one.

Environment Variables Matter More Than You Think

API keys, database credentials, secrets, and configuration values should never be hardcoded.

More importantly, make your application fail fast when required variables are missing.

A clear startup error is much better than mysterious runtime failures.

Docker Solves Many Problems—but Not All of Them

Docker makes applications portable and reproducible, which is why I use it for my projects.

However, Docker doesn't magically fix configuration issues.

If your build succeeds but the application doesn't work, the problem is often in networking, volumes, permissions, or configuration rather than Docker itself.

Reverse Proxies Deserve More Respect

I underestimated how important a reverse proxy like NGINX is.

Routing requests correctly, serving frontend assets, forwarding API calls, and handling HTTPS all become much easier once it's configured properly.

Learning how requests flow through your application stack is worth the effort.

Automate Deployments Early

Manual deployments work...

Until you forget a step.

Automating builds and deployments gave me more confidence and reduced mistakes.

Even a simple CI/CD pipeline is better than copying files manually.

Deployment Is Part of Software Engineering

Writing code is only one part of building software.

Deployment, monitoring, logging, backups, security, and maintenance are just as important.

The sooner you start treating deployment as part of development rather than an afterthought, the better engineer you'll become.

Final Thoughts

Looking back, deployment taught me more about software engineering than many tutorials ever did.

Every failed deployment forced me to understand my application a little better.

If you're building side projects, don't stop after getting them to run locally.

Deploy them.

That's where the real learning begins.

What deployment lesson taught you the most? I'd love to hear your experience in the comments.

What If Every Stadium Had an AI Copilot?

Pratik Dhore — Mon, 13 Jul 2026 14:43:02 +0000

ArenaMind 🏟️🧠

This is a submission for "Weekend Challenge: Passion Edition" (https://dev.to/challenges/weekend-2026-07-09).

What I Built

I'm excited to share ArenaMind, an AI-powered smart stadium platform that I built for the Google GenAI Hackathon.

The challenge was to reimagine how Generative AI could transform the experience of hosting one of the world's largest sporting events—the FIFA World Cup 2026.

Rather than building another chatbot, I wanted to create a platform that delivers meaningful, real-world value for both football fans and stadium operations teams. ArenaMind combines the reasoning capabilities of Google Gemini with deterministic backend workflows, ensuring reliable assistance even during high-footfall events where accuracy and responsiveness are critical.

Using Google Gemini Function Calling, the AI understands user intent and invokes backend services to provide personalized, context-aware responses.

👥 Features for Fans

🌍 Multilingual voice and chat assistant supporting English, Spanish, Portuguese, French, Hindi, and Arabic
🎟️ QR e-ticket awareness for personalized gate and seat navigation
♿ WCAG 2.1 AA accessible routing for wheelchair users and step-free navigation
🚻 Real-time food stall and restroom queue monitoring

🏟️ Features for Stadium Operations

📊 Interactive crowd congestion heatmaps
🔮 Predictive crowd overload forecasting with proactive mitigation alerts
💬 Natural-language Operations Assistant for venue staff
🚨 AI-powered incident triage with automatic P1–P4 severity classification

The passion behind ArenaMind was to demonstrate that AI can do much more than answer questions—it can improve accessibility, reduce congestion, enhance safety, and create a better live event experience for everyone.

Demo

Project Screenshots

Fan Experience

"Fan App Home page" (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/j4rj2stb0ryssb66il59.png)

"Fan AI chat navigation" (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/a7cl9cylmgt19k2tixsf.png)

"Fan AI Smart redirection card" (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/cm0xascqxai9e2i8nwuw.png)

Operations Dashboard

"Organizer command center heatmap" (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/y1u1twqpw2n07jv7ztvt.png)

"Organizer AI Ops Copilot" (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/16b9rirbuznyzrmrxmdk.png)

(Add your deployed application or demo video here if available.)

Code

Tech Stack

Google Gemini
TypeScript
React
Node.js
PostgreSQL
Docker
SOLID Architecture

(Add your GitHub repository here if it is public.)

How I Built It

ArenaMind follows a modular architecture that combines AI reasoning with deterministic backend services.

Google Gemini serves as the intelligent orchestration layer using Function Calling. Instead of generating responses alone, Gemini invokes backend APIs responsible for navigation, crowd analytics, queue information, accessibility routing, and incident management. This approach ensures responses remain grounded in real operational data while maintaining reliability if AI services become unavailable.

The frontend was developed using React and TypeScript, while the backend leverages Node.js with PostgreSQL for structured operational data. Docker was used to containerize the application, making deployment consistent across environments.

One of the most rewarding aspects of the project was designing a system where AI enhances decision-making without becoming a single point of failure. Critical workflows remain deterministic, while Gemini adds natural language understanding and intelligent orchestration on top.

Building ArenaMind reinforced my belief that the future of Generative AI lies not only in conversation but in empowering real-world systems that improve accessibility, navigation, crowd management, and operational efficiency.

Prize Categories

Best Use of Google AI

ArenaMind is built around Google Gemini Function Calling, using Gemini as the intelligent decision-making layer that coordinates real-time backend services to provide contextual, reliable assistance for both fans and stadium operators.

Thank you for reading!

A big thank you to Google for Developers and Hack2Skill for organizing such an inspiring hackathon.

If you were attending the FIFA World Cup 2026, which ArenaMind feature would you use first? I'd love to hear your thoughts and feedback!

EarthPulse AI — Hack2Skill Challenge 3: Carbon Footprint Awareness

Pratik Dhore — Sun, 21 Jun 2026 02:43:55 +0000

🚀 Had a blast participating in the Hack2Skill Virtual Hackathon tackling Challenge 3: Carbon Footprint Awareness Platform!

Instead of just building a standard tracking app, I wanted to experiment a bit for fun. This hackathon was promoting the use of AntiGravity, so I decided to dive in and use it for the very first time.

My biggest takeaway? The developer experience was incredibly smooth. Integrating AntiGravity to handle the application logic made building out EarthPulse AI a really great learning curve, especially under a hackathon timeline.

The app translates daily habits—like commuting and energy use—into visual data insights to help people step up their sustainability game.

Check out the live link or dive into the code below to see how it came together:
🌐 Live Application: https://drpratik.github.io/EarthPulse-AI/
💻 Codebase: https://github.com/DrPratik/EarthPulse-AI/

Always great to walk away from a hackathon with a new tool in the toolkit! 🛠️

WebDev #AntiGravity #Hackathon #GreenTech #BuildInPublic #SoftwareEngineering