DEV Community: Dipesh Sapkota

#IOE Admission Hub: Building a Rank Predictor and Campus Explorer for Nepal

Dipesh Sapkota — Mon, 12 Oct 2026 07:07:10 +0000

Some web projects start with a technology you want to learn. Others start with a problem you want to make easier.

IOE Admission Hub started with the second idea: creating a more approachable way for engineering aspirants in Nepal to explore admission options.

The project brings together a rank-prediction tool, a campus-exploration experience, and an admission-focused website in one place. The aim is to give students a clearer starting point when researching their possible paths into engineering.

🌐 Live project: https://ioe-admission.dipeshsapkota7.com.np/

▶️ Watch the website demo: https://youtu.be/y7I_3Zvlj_Q

The problem I wanted to address

For students preparing for engineering admission, researching colleges and understanding possible outcomes can take time. Information may need to be checked across multiple sources, and knowing what to look for isn't always obvious at the beginning.

The challenge isn't just finding information. It's making sense of it.

I wanted to explore how a focused web application could help students move from general questions to a more organized exploration of their options.

That meant thinking about the purpose of the product before thinking about individual features.

Who is the website for? What does a student want to accomplish? Which tools might help them begin making informed decisions?

IOE Admission Hub grew out of those questions.

Introducing IOE Admission Hub

IOE Admission Hub is a web project for students exploring engineering admission in Nepal.

Its main focus is helping users investigate possible admission outcomes and explore engineering campuses through a dedicated online experience.

Rather than presenting the project as an official admission authority, I see it as a supplementary resource that can help students begin their research and organize their thinking.

The live website is available here:

https://ioe-admission.dipeshsapkota7.com.np/

The core features

Rank Predictor: exploring possible outcomes

The rank predictor is one of the project's central features.

For an engineering aspirant, a prediction can be a starting point for researching possible options and planning what to investigate next.

The important distinction is between a prediction and an official result. A tool can help someone explore scenarios, but it cannot guarantee a campus placement or replace the rules and notices issued by the relevant admission authority.

I want the role of this feature to be clear: support exploration, not promise an outcome.

Campus Explorer: discovering available options

Students need a way to explore campuses while considering their next steps.

The Campus Explorer gives the website a dedicated space for campus discovery. It complements the rank-prediction experience by helping users think about the institutions they may want to investigate.

Together, these features support a more structured approach to admission research: explore possibilities, learn about campuses, and then verify the details that matter through reliable sources.

A focused experience for engineering aspirants

The project is organized around a specific audience and purpose: students exploring engineering admission in Nepal.

That focus matters. A useful education-related website shouldn't force visitors to figure out why it exists or where to begin. Its purpose should be clear from the experience itself.

IOE Admission Hub is my attempt to build around that principle.

Watch the project demo

I recorded a walkthrough of the website so you can see the project directly rather than relying only on written descriptions.

You can also explore the live website while reading:

Visit IOE Admission Hub

Product thinking matters as much as implementation

One of the things I value about building practical projects is that they encourage you to think about the people using the result.

A feature can work correctly and still leave users confused. A page can contain useful information and still make it difficult to decide where to start.

For a website related to education and admission, those details matter. Students may be using it while making decisions that affect their academic plans, so the experience needs to be understandable and the limitations need to be communicated honestly.

A rank prediction should be presented as an estimate. Campus information should be checked for accuracy. Important deadlines and admission rules should be verified through official sources.

These aren't just content considerations; they're part of building a responsible student-facing tool.

What could come next?

IOE Admission Hub is a project that can evolve as its audience and admission-related needs become clearer.

Some possible areas to explore in future iterations include:

Clearer campus comparison tools.
More transparent explanations of rank-prediction assumptions.
Better organization of admission-related resources.
Improvements to mobile usability and navigation.
More prominent guidance for verifying official admission information.

These are possible directions rather than claims about features that are already implemented. The priority should be to add improvements that solve real problems for students.

Why I built it

For me, this project is an example of turning a practical idea into a web-based resource.

I enjoy building things that people can interact with, explore, and potentially use to solve a real problem. IOE Admission Hub gave me an opportunity to approach web development from that perspective: start with an audience, identify a need, and shape the experience around it.

It's also a reminder that a project doesn't have to solve every part of a problem to be worthwhile. It can begin by making one part of a process easier and improve from there.

Explore the project

Here are the links if you'd like to take a closer look:

Live website: https://ioe-admission.dipeshsapkota7.com.np/
YouTube demo: https://youtu.be/y7I_3Zvlj_Q

If you explore it, I'd love to know what you think.

What's one thing you wish was easier when researching engineering admission in Nepal?

That kind of feedback is valuable because the best next feature is usually the one that addresses a real user need.

Thanks for checking out IOE Admission Hub.

Building an ESP32-Based IoT Emergency Response System for the Elderly

Dipesh Sapkota — Thu, 01 Oct 2026 17:37:57 +0000

Building an ESP32-Based IoT Emergency Response System for the Elderly

By Dipesh Sapkota

Technology becomes meaningful when it moves beyond the screen and addresses problems that affect people's everyday lives.

As a Computer Engineering student at IOE Thapathali Campus, Nepal, I am interested in the intersection of software development, electronics, and practical engineering. Building web applications has taught me how to approach software architecture and logical problem-solving. Working with embedded hardware introduces another dimension: software must interact with physical signals, electronic components, and real-world operating conditions.

That perspective inspired one of my hardware engineering projects: an IoT-Based Emergency Response System for the Elderly, built around an ESP32 microcontroller, motion and biopotential sensing modules, embedded C++ firmware, wireless communication, and printed circuit board (PCB) design.

The objective was to explore how a connected embedded system could monitor sensor inputs, evaluate predefined conditions, and initiate an alert workflow without relying entirely on someone manually activating an emergency button.

This project brought together several important areas of computer engineering, including microcontroller programming, sensor interfacing, circuit design, wireless communication, and hardware prototyping.

1. What Problem Does the System Address?

Conventional personal emergency alarms often depend on manual activation. However, a person experiencing a sudden fall or another unexpected event may not always be able to reach a phone or press an SOS button.

An automated monitoring system offers an alternative approach: collect sensor readings, evaluate relevant changes, and initiate an alert when predefined conditions are met.

The main goals of this project were to explore a system capable of:

Sensor-based monitoring: Collect motion-related and other relevant sensor readings.
Automated event evaluation: Process sensor inputs to identify conditions that may require attention.
Wireless communication: Use the ESP32's Wi-Fi capabilities to transmit alert information.
Hardware integration: Bring the controller and sensor modules together through a structured circuit design.
PCB-based prototyping: Explore a more organized hardware implementation than a temporary breadboard arrangement.

The goal is not to claim that sensors can independently diagnose a medical emergency. Instead, the project explores how embedded systems and IoT communication can support an emergency-notification workflow.

2. System Architecture: From Sensor Data to Alert

The system can be understood as a sequence of interconnected stages:

Sensor acquisition → Embedded processing → Event evaluation → Wi-Fi communication → Alert delivery

Each stage introduces its own engineering challenges.

ESP32 Microcontroller: The Processing Core

The ESP32 serves as the central controller for sensor interaction and wireless communication.

Its integrated Wi-Fi capabilities make it useful for IoT prototypes that need to communicate with another device or service without requiring a separate Wi-Fi module.

Within this project, the controller provides a platform for:

Initializing and reading connected sensors.
Processing sensor data through embedded firmware.
Evaluating readings against predefined conditions.
Coordinating alert-related operations.
Communicating with a remote endpoint over Wi-Fi.

The challenge is not simply to perform these operations, but to organize them so that a slow network request does not unnecessarily interrupt essential monitoring tasks.

Motion Sensors and Biopotential Monitoring

The sensor layer incorporates motion-sensing and biopotential monitoring modules.

Motion sensors can provide information about movement and changes in orientation, depending on the specific hardware. Biopotential modules measure electrical signals associated with biological activity, with interpretation depending on the sensor, its placement, and the processing method.

Integrating these sensors requires careful consideration of:

Sampling frequency and timing.
Signal quality and electrical noise.
Sensor calibration and operating limits.
Filtering and interpretation of readings.
Criteria for identifying potentially significant events.
Handling disconnected sensors or invalid measurements.

These considerations matter because normal movement, electrical interference, and sensor artifacts can produce readings that resemble unusual events.

A reliable implementation needs to distinguish raw sensor measurements from the conclusions drawn from those measurements.

Embedded C++ Firmware

The firmware connects the sensor hardware with the application's decision-making logic.

C++ provides the programming foundation for organizing sensor acquisition, event evaluation, and communication into manageable components.

A maintainable architecture can separate the firmware into distinct responsibilities:

Sensor management: Initialize devices and acquire measurements.
Data processing: Validate and process readings.
Event evaluation: Apply predefined rules to determine whether an alert should be considered.
Communication management: Transmit event information over the network.
Error handling: Manage failed readings, network interruptions, and unexpected operating conditions.

Separating these responsibilities makes debugging easier and reduces unnecessary dependencies between components.

For example, losing a Wi-Fi connection should be handled as a communication failure rather than automatically being interpreted as a sensor event.

Interrupts and non-blocking operations can also be valuable in embedded applications, depending on the timing requirements. However, their use should reflect the actual implementation, and interrupt handlers should remain short enough to avoid disrupting other tasks.

Wi-Fi Communication and Alert Delivery

Wireless communication provides the link between the embedded device and an external notification service.

However, sending a network request does not automatically guarantee that an alert has reached its intended recipient.

A more robust implementation should consider:

Connection monitoring.
Network timeouts.
Failed requests and controlled retries.
Recovery after Wi-Fi disconnection.
Confirmation that the receiving service accepted an alert.
Clear handling of communication failures.

These are important system-design considerations because the usefulness of an emergency-response prototype depends on the complete path from sensor input to notification delivery.

PCB Design and Hardware Integration

PCB design introduces the physical engineering constraints that connect the electronic components into a practical assembly.

A custom printed circuit board can help organize the microcontroller, sensors, power connections, and supporting components into a more structured design.

Important considerations include:

Component placement and footprint accuracy.
Power distribution and grounding.
Trace routing and signal integrity.
Noise-sensitive analog signal paths.
Connector accessibility and maintainability.
Inspection and testing before operation.

Power fluctuations and switching activity can affect sensitive electronic signals. Appropriate decoupling, grounding, and layout practices can help reduce these issues, although the effectiveness of a particular design must be verified through testing.

3. Hardware and Software Technology Stack

The project brings together embedded computing, electronic sensing, and circuit design.

Component	Purpose
ESP32	Embedded processing and Wi-Fi connectivity
Motion sensors	Collection of motion-related measurements
Biopotential modules	Acquisition of biological electrical signals
C++	Embedded firmware development
Wi-Fi	Wireless communication for alert transmission
Circuit design tools	Schematic development and circuit planning
PCB design and fabrication	Physical integration of electronic components

The specific capabilities of the finished prototype depend on the sensors, firmware, circuit implementation, and communication endpoint used.

4. Key Engineering Challenges and Lessons Learned

Handling Sensor Noise and False Alerts

Sensor measurements are not always clean. Electrical interference, unstable connections, normal movement, and variations in the environment can affect readings.

A practical detection system therefore needs a defined approach to signal processing and event evaluation.

Depending on the sensor and application, this might involve filtering, thresholding, time-based confirmation, or other techniques.

The important principle is that a single unexpected reading should not automatically be treated as evidence of an emergency.

Understanding Hardware and Software Interactions

Embedded debugging often requires investigating several layers at once.

A problem that appears to originate in the code could actually result from incorrect wiring, unstable power, sensor configuration, timing, or assumptions about the sensor's output.

Testing components individually before integrating them can help isolate faults and simplify troubleshooting.

This experience reinforces an important engineering lesson: reliable embedded software depends on understanding the hardware on which it operates.

PCB Layout and Signal Integrity

A circuit schematic describes electrical connections, but the physical layout introduces additional constraints.

Grounding, component placement, trace routing, and power distribution can all affect circuit behavior. Sensitive analog signals may require particular attention when positioned near noisy digital circuitry.

These considerations make PCB design an important part of the engineering process rather than simply a step for making a prototype look more finished.

Designing Beyond a Successful Demonstration

A prototype that works during a demonstration has not necessarily been validated for every operating condition.

A more complete evaluation would investigate sensor behavior, alert delivery, network failures, power interruptions, recovery behavior, and the frequency of false or missed alerts.

For an application associated with personal safety, these limitations must be understood before making claims about real-world reliability.

5. How Could the System Be Improved?

Several development directions could make an ESP32-based emergency response system more robust and easier to evaluate.

1. Modular Firmware Architecture

Separating sensor acquisition, event evaluation, and network communication would improve code organization and simplify testing.

2. Reliable Notification Delivery

Connection monitoring, controlled retries, delivery acknowledgements, and explicit error states could help the system respond more clearly to communication failures.

3. Sensor Calibration and Validation

Testing sensors under different conditions could help establish more appropriate detection criteria and reduce unnecessary alerts.

4. Power Optimization

Measuring actual power consumption and evaluating suitable sleep modes could help determine whether extended battery operation is practical.

5. Event Logging and Diagnostics

Recording relevant events and system errors would make it easier to understand unexpected behavior during development and testing.

6. Caregiver Notification Interface

A dedicated interface could present event information, timestamps, connection status, and acknowledgement states if the required application and backend were implemented.

7. Systematic Reliability Testing

Testing normal operation, sensor disconnection, network loss, repeated events, and recovery behavior would provide stronger evidence of the system's actual capabilities.

These improvements represent possible development directions and should not be interpreted as features already implemented in the current prototype.

6. What This Project Taught Me About Computer Engineering

This project helped me understand how closely embedded hardware and software depend on each other.

In web development, a problem may appear as a failed request or an unexpected application state. In embedded systems, the cause may be further down the chain: an unstable electrical signal, a timing issue, a sensor configuration problem, or a communication failure.

Diagnosing these issues requires a broader perspective than looking at code alone.

The project also reinforced the difference between making a system work once and designing it to behave predictably under different conditions.

That distinction is particularly important when working on applications related to personal safety. Engineering involves not only implementing functionality, but also identifying limitations, evaluating failure cases, and testing assumptions.

7. Frequently Asked Questions

What is an ESP32-based IoT emergency response system?

It is an embedded system that uses an ESP32 microcontroller to process sensor inputs and communicate selected events over a network. Its capabilities depend on the connected sensors, firmware, and alert-delivery infrastructure.

Why use ESP32 for an IoT project?

The ESP32 combines microcontroller capabilities with integrated wireless connectivity, making it suitable for prototypes that require sensor interaction, local processing, and Wi-Fi communication.

Which programming language is used for ESP32 development?

ESP32 applications can be developed using C or C++, including through the Arduino framework and ESP-IDF. This project uses C++ for its embedded firmware.

What is the role of sensors in an emergency alert system?

Sensors collect measurements that firmware can process to identify predefined conditions. Their readings require appropriate interpretation, and they cannot independently establish that a medical emergency has occurred.

Why is PCB design important in embedded systems?

A PCB provides the physical layout and electrical connections needed to integrate components. Good design supports organized assembly, maintainability, and signal integrity.

Is an IoT emergency response prototype a medically validated device?

Not automatically. A working prototype does not establish clinical accuracy or dependable emergency detection. Real-world safety applications require suitable validation, safeguards, and consideration of applicable regulations.

Conclusion

Building an IoT-based emergency response prototype gave me an opportunity to explore the relationship between microcontroller programming, sensor integration, wireless communication, and PCB design.

The most valuable lesson was that a connected device is more than the sum of its components. Its behavior depends on how every layer interacts, how failures are handled, and how thoroughly the design is tested.

As I continue developing my skills in computer engineering, I want to explore more projects that connect software logic with physical systems and address practical engineering challenges.

The next step is not simply adding more features. It is making the system easier to test, understand, and evaluate.

Explore My Work

I share projects involving software development, interactive developer tools, and engineering through my online profiles.

Portfolio: Dipesh Sapkota — Personal Website
GitHub: dszae — Project Repositories
LinkedIn: Connect with Dipesh Sapkota

If you work with ESP32, IoT, embedded C++, electronics, or PCB design, I would be interested in hearing about your experiences with hardware debugging and reliable embedded system design.

About the Author

Dipesh Sapkota is a Computer Engineering student at IOE Thapathali Campus in Nepal, interested in embedded systems, software development, and AI/ML. He also works on web applications, developer tools, video editing, and motion graphics.

His interests span the intersection of software and hardware, with a focus on building practical projects and learning through implementation.

Explore his work on his personal portfolio, GitHub, or LinkedIn.

Building Git Visualizer: Making Git Easier to Understand Through Interactive Visuals

Dipesh Sapkota — Thu, 01 Oct 2026 17:37:42 +0000

Building Git Visualizer: Making Git Easier to Understand Through Interactive Visuals

Git is one of those tools that almost every developer eventually needs to learn. But when you're starting out, understanding what actually happens behind commands like git checkout, git merge, and git rebase can be confusing.

You can memorize commands, read documentation, and follow tutorials, but sometimes you still wonder what changed inside your repository after running a command.

I wanted to explore a different approach: what if learning Git felt more like exploring a visual system than memorizing terminal commands?

That idea led me to build Git Visualizer, an interactive web project designed to make Git concepts easier to understand through visual representations of commits, branches, and repository state.

I'm still learning as a Computer Engineering student, and projects like this give me an opportunity to turn concepts I find interesting into something other people can explore.

🌐 Try Git Visualizer

💻 Explore the source code on GitHub

🎬 Watch Git Visualizer in Action

I've also created a video showcasing the project. Instead of just describing what I built, here's a chance to see it for yourself.

If the video doesn't appear in the editor preview, you can watch it directly on YouTube.

Why I Wanted to Build This

One thing I've noticed while learning programming is that some concepts become much easier when you can actually see them.

Git is a good example.

A repository isn't simply a folder containing files. It also has a history of commits, references to different points in that history, and branches that let you work on different lines of development.

Understanding how these pieces fit together takes time.

Here are a few concepts that can be difficult for beginners:

Working directory: Where you make changes to your files.
Staging area: Where you prepare changes before committing them.
Commits: Recorded snapshots that form part of your project's history.
Branches: References that help you organize separate lines of development.
HEAD: The reference that identifies your current position in the repository.
Merging: Bringing changes from different lines of development together.

Reading about these concepts is useful, but seeing how they relate to one another can make them easier to understand.

That was the main idea behind Git Visualizer.

How Git Visualizer Works

I built Git Visualizer as a web application using React and Tailwind CSS. The project focuses on representing Git concepts visually and allowing users to explore how common operations affect the represented repository state.

1. Visualizing commits and branches

Instead of relying only on terminal output, Git Visualizer presents commit history as a visual graph.

This helps you follow connections between commits and understand how branches relate to the repository's history.

A visual graph can make the structure of a repository easier to follow, especially when you're still getting comfortable with Git.

2. Exploring common Git operations

Git Visualizer lets users explore simulated operations such as:

commit
branch
checkout
merge

The idea is to connect an operation with its visible result. Rather than just reading what a command means, you can explore how the represented state changes.

This is particularly useful when trying to understand how branches and commit references interact.

3. Understanding commit relationships

Commits are connected through parent relationships, creating the history of a repository.

Representing those relationships visually helps explain why Git is often described using a directed acyclic graph, or DAG.

Instead of treating commit history as a simple list, you can begin to understand how different lines of development connect.

4. Making technical concepts more approachable

A developer tool doesn't need to sacrifice usability to explain technical ideas.

I wanted the interface to make Git concepts easier to explore without requiring users to understand every detail of Git's internal implementation first.

That balance between technical representation and clear presentation is something I continue to think about when working on my projects.

The Engineering Challenges

Building the interface was only one part of the work. The more interesting challenge was thinking about how to represent Git operations and their relationships consistently.

Designing a readable commit graph

As commit histories become more complex, a graph can quickly become difficult to follow.

Branches need enough visual separation, connections between commits need to remain understandable, and the layout needs to communicate relationships without overwhelming the user.

This makes graph layout more than just a styling problem. It is also an information-design problem.

Managing application state

Interactive applications need a consistent way to represent their current state.

For a Git visualization tool, that means thinking about how operations affect commits, branches, and references, and ensuring that the interface reflects those changes coherently.

React gave me a way to structure the interface around state and reusable components while working through these challenges.

Keeping the experience understandable

A feature can work as intended and still be difficult to understand.

That is why usability matters just as much as functionality. The challenge is not only to represent a technical concept but also to make that representation useful to someone learning it.

These are areas I want to keep improving as I continue developing the project.

Technologies Used

The project brings together several web development technologies:

React: For building the interactive user interface.
JavaScript: For application logic and interactions.
Tailwind CSS: For styling the interface.
SVG-based visualization: For drawing and presenting graph elements.

Working with these technologies gave me an opportunity to think about more than how a page looks. I also had to consider how data, application state, and visual elements work together.

What I Learned From Building Git Visualizer

One of the biggest things this project has reinforced for me is that building a useful tool involves more than making it work.

You have to think about how people understand information, which parts of a concept are difficult to grasp, and how an interface can make those parts clearer.

I've also learned to pay more attention to the relationship between application logic and visual presentation. When the underlying state changes, the interface needs to communicate that change in a way users can understand.

Most importantly, the project has reminded me that building something for learning can also improve your own understanding of the subject.

You start with an idea, work through the implementation, encounter problems you didn't anticipate, and gradually develop a better understanding of both the technology and the concept you're trying to explain.

Try Git Visualizer Yourself

If you're learning Git, teaching version control, or simply curious about how commits and branches fit together, I'd love for you to explore the project.

🌐 Live project: Git Visualizer
🎬 Project video: Watch on YouTube
💻 Source code: GitHub repository
👨‍💻 More of my work: Dipesh Sapkota's portfolio
🐙 GitHub profile: github.com/dszae
✍️ DEV Community profile: dev.to/dszae

I'm continuing to learn and improve my projects, so I don't consider Git Visualizer a complete representation of every Git feature or workflow. It's an ongoing project built around one simple goal: making version control concepts easier to explore visually.

If you try it, I'd genuinely like to hear what you think.

Which Git concept was the hardest for you to understand when you first started learning — branches, merging, rebasing, HEAD, or something else?

Share your thoughts in the comments. I'd love to learn from your experiences too.

About Me

I'm Dipesh Sapkota, a Computer Engineering student at IOE Thapathali, Nepal. I enjoy building web projects, exploring technology, and working on creative projects involving video editing and motion graphics.

I'm using these projects as a way to learn by building, experiment with new ideas, and gradually improve as a developer.

You can explore more of my work on my personal portfolio or connect with me on GitHub.

Git #GitVisualizer #React #WebDevelopment #JavaScript

Building Sportivo: A Live Sports Web App with React

Dipesh Sapkota — Thu, 01 Oct 2026 17:37:13 +0000

Building Sportivo: How I Built a Live Sports Web App with React

Sports fans often want one simple thing: a convenient way to find the matches they're interested in without fighting through a confusing interface.

That sounds straightforward, but building a useful sports web application involves several moving parts. Fixtures need to be organized, navigation needs to feel natural, search should respond quickly, and the interface needs to work across different screen sizes.

I built Sportivo to explore these challenges and create a sports-focused web experience that brings match discovery and streaming-related functionality together.

🌐 Live website: https://sportivo.dipeshsapkota7.com.np/

🎥 Watch the updated project demo: https://youtu.be/rfxeT_Dl7pE

💻 GitHub repository: https://github.com/dszae/sportivo

What Is Sportivo?

Sportivo is a sports web application built to make it easier for users to explore sports fixtures, find matches, and navigate a sports-focused interface.

The project brings together match discovery, fixture browsing, search, and playback-source selection in a single web experience.

Rather than treating the project as just another frontend exercise, I wanted to explore how these different pieces could work together in a practical application.

You can try the current version here: Sportivo — Live Website.

Why Did I Build Sportivo?

I wanted to build something interactive that went beyond a static landing page.

Sports websites can contain a lot of information, especially when multiple sports, leagues, teams, and fixtures are involved. If that information is poorly organized, users have to spend more time navigating the interface than finding what they came for.

This gave me a useful development challenge: create a sports-focused interface where discovery, navigation, and playback options feel like parts of one application.

Sportivo became an opportunity to work on frontend architecture, dynamic content, application state, responsive layouts, and the details that make an interactive website easier to use.

What Features Does Sportivo Include?

Sportivo focuses on several areas that contribute to the overall experience.

1. How Does Sportivo Organize Sports Fixtures?

The application is designed around browsing sports fixtures and making match information easier to navigate.

Organizing fixtures by relevant categories helps users narrow their attention to the events they're interested in instead of working through one undifferentiated list.

The usefulness of this feature depends on the quality and freshness of the underlying fixture data, so data handling is an important part of building this type of application.

2. How Does the Match Search and Filtering Work?

Search and filtering help users find relevant fixtures without manually browsing every available entry.

The intended experience is simple: users can narrow down matches using relevant information such as team names, leagues, or sports, depending on the available data and implemented filters.

This is an important usability feature because a growing list of fixtures becomes harder to navigate as more events are added.

3. Why Is Multi-Server Playback Useful?

Sportivo includes a multi-server playback interface that allows users to select between available playback sources.

Providing a server selector gives users another option when a particular source is unavailable or doesn't work as expected. However, switching sources cannot guarantee uninterrupted playback because each source may have its own availability, compatibility, and network limitations.

For embedded third-party players, the application also needs to account for browser restrictions and the behavior of external services.

4. How Does Sportivo Support Direct Match Links?

Direct links can make it easier to return to a specific match or share a particular fixture with someone else.

When a web application represents a selected item in its URL, users can often navigate back to that state more conveniently than if the selection existed only inside the current page.

This is a useful design consideration for interactive websites because URLs can connect the interface to the user's browsing and sharing workflow.

The exact behavior depends on how each route or query parameter is implemented in the current version.

What Technologies Did I Use to Build Sportivo?

The original project setup uses a modern frontend stack centered on React.

The technologies identified in the project include:

React: Building reusable interface components and interactive user experiences.
Vite: Providing the frontend development and build tooling.
Tailwind CSS: Styling the interface with utility classes and supporting responsive layouts.
JavaScript: Implementing application behavior and user interactions.

These technologies make it possible to develop a component-based interface while keeping the development workflow relatively fast.

A key part of building with a frontend framework is deciding how to represent the application's data and how the interface should respond when that data or the user's selection changes.

What Were the Main Technical Challenges?

Handling Dynamic Match Information

Sports fixtures are time-sensitive. Their usefulness depends on the data being relevant, correctly categorized, and presented clearly.

A robust implementation needs to account for unavailable data, changes in fixture information, and differences between the data source and what the interface expects.

Managing Playback Sources

Third-party video players can behave differently depending on the browser, source, network, and embedding restrictions.

A playback interface therefore needs to handle unavailable sources gracefully rather than assuming every embedded player will work in every environment.

Designing a Responsive Interface

A sports application needs to remain usable on different screen sizes.

Fixture lists, search controls, match details, and player containers all compete for limited screen space, particularly on mobile devices. Responsive layout decisions should prioritize readability and convenient navigation rather than simply shrinking the desktop design.

Keeping the Interface Understandable

An interface can contain many features and still feel difficult to use.

I wanted Sportivo's primary actions—finding a match, exploring fixtures, and selecting available playback options—to be straightforward to understand.

That means the design needs to communicate the purpose of each control and provide useful feedback when something isn't available.

What Did I Learn From Building Sportivo?

Building Sportivo reinforced the idea that an interactive application is more than a collection of components.

Each feature affects the overall user experience. Search is only useful when the data is organized consistently. A player selector is only useful when the available sources are clearly represented. A responsive layout is only successful when users can still understand and operate the interface on smaller screens.

It also highlighted the importance of handling external dependencies carefully. When an application relies on third-party data or embedded media, the developer cannot control every part of the experience.

Good interface design should account for those limitations instead of assuming that every request or player will always succeed.

What Could Be Improved in Sportivo Next?

There are several areas worth exploring as the project evolves:

Better feedback when fixture data or playback sources are unavailable.
More informative match and league filters.
Improved accessibility for keyboard and assistive-technology users.
Additional responsive-layout refinements.
Clearer loading, empty, and error states.
Better documentation of the data sources and the behavior of external integrations.

These are possible directions for continued development, not a claim that every item is already implemented.

The most valuable next step would be to prioritize improvements based on real usability issues and test them against the actual application.

Where Can You See the Sportivo Demo?

I recorded an updated walkthrough to show the project in action.

If Hashnode doesn't convert the Markdown embed into a video player in your editor, use the editor's /embed block and paste the YouTube URL.

You can also explore the project directly:

🌐 Live website: https://sportivo.dipeshsapkota7.com.np/
🎥 YouTube demo: https://youtu.be/rfxeT_Dl7pE
💻 GitHub repository: https://github.com/dszae/sportivo

Who Built Sportivo?

I'm Dipesh Sapkota, a Computer Engineering student at IOE Thapathali in Nepal, interested in software development and creative technology.

I enjoy building projects that combine technical problem-solving with practical user experiences. Sportivo is one part of that journey: an opportunity to work on an interactive web application, explore frontend development challenges, and keep improving through hands-on projects.

You can find more about my work here:

Portfolio: https://www.dipeshsapkota7.com.np/
GitHub: https://github.com/dszae

Final Thoughts

Sportivo started as an opportunity to build a more engaging sports web application, but the development process also raised broader questions about usability, dynamic data, external integrations, and responsive design.

Those are the challenges that make real-world web development interesting. Getting a page to render is one step; making the whole experience understandable and resilient is another.

I'm continuing to develop my skills through projects like this, and Sportivo is a work in progress that can improve through testing, feedback, and thoughtful iteration.

Try Sportivo and let me know what you think: https://sportivo.dipeshsapkota7.com.np/

What would you improve first in a sports web application like this: match discovery, the interface, or playback reliability?

Thanks for reading!

Launching My Digital Portfolio: Bridging Code & Creative Media

Dipesh Sapkota — Sat, 12 Sep 2026 03:54:33 +0000

I’m excited to officially launch my new digital portfolio—a central hub where my background in Computer Engineering intersects with my passion for visual media and AI/ML technologies. 🚀

Over the last few months, I’ve focused on building tools designed to solve concrete problems and simplify complex workflows. My new site highlights my latest technical builds:

🎓 IOE Admission Hub: A comprehensive analytics toolkit for Tribhuvan University engineering applicants, featuring statistical rank predictions and automated priority form generation.
🌿 Git Visualizer: An interactive, visually driven learning tool designed to demystify version control through live, dynamic data-flow mapping.

The portfolio is built from the ground up using React, Vite, and Tailwind CSS, featuring a custom interactive canvas engine and a strict focus on performance optimization.

Check out the live site and explore the projects here: https://www.dipeshsapkota7.com.np/

I’d love to hear your thoughts or feedback on the interactive elements!

ComputerEngineering #WebDevelopment #ReactJS #SoftwareEngineering #PortfolioLaunch #TechNepal #UIUX #DeveloperCommunity