DEV Community: Kelechukwu Amadi-Keke

I Built My Own Analytics Platform Instead of Paying for PostHog

Kelechukwu Amadi-Keke — Sun, 07 Jun 2026 23:00:00 +0000

Introduction

Let me clear one thing up right out of the gate: this is not a teardown of PostHog. In fact, PostHog is an incredible piece of software and one of the primary inspirations for my journey.

But while grinding away on my own side projects, I kept hitting the exact same wall. I desperately wanted product analytics, system monitoring, and operational visibility, but I didn't want the cognitive overhead of managing four different platforms. I didn't want to copy-paste half a dozen different tracking scripts into my frontend, and I definitely didn't want another stack of recurring monthly SaaS bills.

So, like any developer facing a minor inconvenience, I decided to spend weeks of my life building my own solution from scratch.

The Stack of Disconnected Tools

Most indie hackers and small dev teams follow a very predictable path when it comes to keeping tabs on their apps:

-They launch with zero observability because they just want to ship.

-They realize they have no idea if anyone is visiting, so they drop in an analytics script.

-Users start complaining about silent crashes, so they sign up for an error-tracking tool.

-The server drops offline while they're asleep, so they set up an uptime ping tool.

-They notice their database queries are lagging, so they look for an API monitoring solution.

Before you know it, your lean side project is held together by duct tape and a collection of disconnected, expensive browser tabs. Each tool solves its individual problem perfectly, but collectively, they introduce massive friction. You find yourself jumping between dashboards just to answer a basic question like, "Did that spike in traffic cause my API response times to degrade?"

I didn't want a suite of tools. I wanted a single, unified lens.

The Blueprint for observe

My checklist was simple. I wanted four distinct capabilities living under the exact same roof, visible on a single glass pane:

-Product Analytics: Understanding user behavior and feature adoption.

-Uptime Monitoring: Knowing the exact minute my servers take a hit.

-Error Tracking: Snagging stack traces before the user bounces.

-API Metrics: Keeping an eye on endpoint latencies and failure rates.

To make this happen without overcomplicating my life, I leaned on a battle-tested, high-performance stack: React on the frontend, FastAPI for the heavy-lifting API gateway, PostgreSQL as the reliable data anchor, and Redis + Celery to handle the asynchronous background queues.

The Hardest Part Wasn't the Tech

Going into this, I assumed the technical hurdles would be the bottleneck. I figured I'd lose sleep over authentication flows, Docker deployments, or wiring up responsive charts.

It turned out those were the easy parts. The real headache, was data modeling and identity resolution.

When you build an analytics engine, you are forced to ask incredibly precise philosophical questions about your data:

-Who exactly is a visitor versus a registered user?

-How do you seamlessly stitch together an anonymous session from a phone with an identified user profile on a desktop three days later without duplicating data?

-If an API endpoint fails, how do you contextually link that specific error to the exact user journey that triggered it?

Figuring out how to link these disparate event streams into a cohesive story was a masterclass in database design. I quickly realized that observability isn't a data collection problem—anyone can dump JSON into a database. It’s a data synthesis problem. The value isn't in storing the events; it's in making those events mean something to a tired developer at 2:00 AM.

Final Thoughts: Should You Build Your Own?

If you are running a fast-growing startup or trying to get a commercial product off the ground, my honest advice is: probably not. Use PostHog, use Plausible, use Sentry. Your time is better spent building your actual core product. Or, if you are an indie dev like me with a small budget? Use Observe.

But I didn't build observe because I thought the market was lacking another dashboard. I built it because I wanted to tear down the black box. I wanted to deeply understand the engineering behind high-throughput data ingestion, and I wanted a tool custom-tailored to how I think and work.

No matter what happens to the project next, the sheer amount of architectural grit I gained from building an analytics pipeline from scratch was worth every single line of code.

Building a PostHog-Like Analytics Platform with FastAPI

Kelechukwu Amadi-Keke — Fri, 05 Jun 2026 00:00:00 +0000

Introduction

At a high level, analytics platforms seem deceptively simple. A user clicks a button, an event payload hits an endpoint, and a pretty dashboard displays the result.

But the moment you sit down to architect one yourself, you realize the rabbit hole goes incredibly deep. I recently built observe, an all-in-one analytics and observability platform, to solve my own dashboard fatigue. Moving from consuming analytics to building the actual pipeline forced me to rethink how data moves through a system.

Here is a look under the hood at the architectural decisions, bottlenecks, and data modeling lessons behind building a telemetry platform from scratch.

The Core Data Unit: The Event

Everything in an analytics platform lives and dies by the event. A lightweight frontend SDK captures user activity in the browser and fires it off to an ingestion endpoint.

A standard payload might look something like this:

JSON

{
  "anonymous_id": "usr_abc123",
  "name": "button_clicked",
  "properties": {
    "element_id": "signup_btn",
    "path": "/pricing",
    "screen_width": 1440    
  }
}

Receiving this JSON is the easy part. The real engineering challenge lies in how you ingest, process, and query this data without locking up your database or making your dashboard crawl.

The Identity Problem: Visitors vs. Users

One of the first structural hurdles I ran into was mapping user identity. You have to explicitly design for two distinct states:

The Visitor (Anonymous): Someone browsing your landing page before they’ve signed up.
The User (Identified): A verified account with a specific ID in your database.

To build a cohesive user journey, your system has to track anonymous activity via local device IDs, store those events, and then dynamically alias or merge that history into the real user profile the exact moment they log in or sign up. If you don't model this relationship correctly from day one, your retention charts and user funnels will be completely broken.

The Production Backend Stack

To handle ingestion and processing without breaking the bank, I settled on a classic, robust asynchronous stack:

-FastAPI: Acts as the high-throughput gateway. It takes incoming HTTP POST requests from the SDK, validates the schema instantly using Pydantic, and offloads the heavy lifting.

-PostgreSQL: Serves as the source of truth for user accounts, session data, and core aggregates.

-Redis: Acts as our ultra-fast caching layer and the message broker handling the system's internal communication.

-Celery: The workhorse that processes event queues and runs background tasks out-of-band.

[ Frontend SDK ] ---> ( FastAPI Ingestion ) ---> [ Redis Queue ] ---> [ Celery Workers ] ---> [ PostgreSQL ]

Why Async Background Processing is Non-Negotiable

When you’re first starting out, writing every incoming event directly to SQL works fine. But at scale, hitting your database on every single page click is architectural suicide; it immediately bottlenecks your API and degrades the end-user experience.

By introducing Celery and Redis into the mix, the FastAPI ingestion endpoint does exactly one job: it validates the JSON format, drops the raw payload into a Redis queue, and immediately returns a 202 Accepted response to the client.

This decoupling unlocks massive performance benefits:

-Event Batching: Celery workers can pool events in memory and perform bulk database inserts (e.g., writing 500 events in a single SQL transaction instead of 500 individual writes).

-Isolated Failure: If the database experiences a sudden spike or goes down for maintenance, the API keeps accepting events. The data sits safely in the Redis queue until the database recovers.

-Heavy Lifting Separation: Background workers handle intensive cron jobs—like running periodic uptime pings, processing historical error rates, and calculating daily usage statistics—without stealing a single CPU cycle from the live API.

Frontend:

For the frontend, I used React paired with modern charting libraries to visualize event streams, error spikes, uptime history, and API response latencies.

Going into this, I assumed the frontend would be the straightforward part. I was wrong. Building a chart is easy; designing a dashboard that helps people make decisions is incredibly difficult.

When you have access to a massive pool of raw event data, the temptation is to graph everything. But endless rows of line charts quickly turn into cognitive noise. The real challenge was exercising restraint—filtering out the vanity metrics and structuring the UI so a developer can log in and see exactly what is broken within three seconds.

What I learned

Looking back at the development of observe, a few foundational rules stood out:

-Observability is a data modeling problem: If your database schemas aren't optimized for time-series data or rapid aggregation, your app will choke as soon as you hit millions of rows.

-Ingestion is easy; analysis is hard: Writing data into a system at high speed is a solved problem. Writing it in a way that allows a user to query complex funnels and cohorts in real-time is where the real engineering happens.

-Simplicity is a premium feature: The ultimate goal isn't to build a tool with the most configuration toggles. It’s to build a tool that gives you the maximum amount of operational clarity with the absolute minimum amount of friction.

Closing Thoughts

Building an analytics engine from scratch completely changed how I view observability tools. What looks like a simple, smoothly updating line graph on your screen is almost always the tip of an iceberg—supported by millions of micro-decisions, background queues, and data pipelines running silently beneath the surface.

Check out Observe: https://useobserve.xyz

This is a submission for the GitHub Finish-Up-A-Thon Challenge

Kelechukwu Amadi-Keke — Tue, 02 Jun 2026 09:46:02 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Over the past few weeks, I built observe., an observability platform designed to help developers understand what is happening inside their applications. I built it because myself and some other Nigerian developers couldn't keep up with the cost of enterprise tools.

The platform combines several capabilities that are often spread across multiple tools:

Product analytics
Uptime monitoring
Error tracking
API monitoring

The goal was simple: provide a single dashboard where developers can answer questions like:

Are users actually using my product?
Which features are being used?
Is my application online?
Are there increasing error rates?
Are API endpoints slowing down?

The project is built with:

FastAPI
PostgreSQL
Redis
Celery
React
TypeScript

What started as an exploration of analytics systems eventually grew into a complete end-to-end product with event ingestion, monitoring services, background workers, dashboards and project management.

Demo

Live Project

Observe.

Source Code
Backend: https://github.com/Im-Kaycee/Observability-backend
Frontend: https://github.com/Im-Kaycee/observability-dashboard

Screenshots

Video Walkthrough

The Comeback Story

This project started as a much smaller analytics experiment.

Initially, the focus was simply recording events from applications and displaying them in a dashboard.

As development continued, I realized that analytics alone only tells part of the story.

Knowing what users are doing is useful, but it doesn't tell you:

When your application is down
Whether APIs are healthy
If users are encountering errors

So I expanded the project into a broader observability platform.

Some of the major additions included:

Event Ingestion Pipeline

I built a system that accepts events from client applications and stores them for analysis.

This required designing concepts such as:

Projects
API keys
Visitors
Users
Events

and understanding how modern analytics platforms associate anonymous activity with identified users.

2.Monitoring Services

I added uptime monitoring and API monitoring so developers can track application health alongside user behavior.

Background Processing

Using Celery and Redis, I introduced background workers for tasks that shouldn't run inside request-response cycles.

Dashboard Experience

One of the biggest improvements was the frontend.

I redesigned the interface around a clean, serious aesthetic with subtle neobrutalist accents to make large amounts of monitoring data easier to navigate.

By the end of the challenge, the project had evolved from a partially completed analytics idea into a fully functional observability platform.

My Experience with GitHub Copilot

GitHub Copilot helped accelerate development throughout the project.

Some of the areas where it was most useful included:

Boilerplate Generation

Copilot was particularly effective at generating repetitive code such as:

CRUD endpoints
Database models
Schema definitions
Validation logic
Refactoring

As the architecture evolved, Copilot helped quickly update code paths and maintain consistency across files.

Frontend Development

Building dashboards often involves repetitive UI patterns. Copilot significantly reduced the time required to create and iterate on components.

Learning and Exploration

One of the most valuable aspects was using Copilot as a development companion while working through unfamiliar implementation details and architectural decisions.

Rather than replacing problem solving, it allowed me to spend more time thinking about system design and product decisions instead of writing repetitive code.

Built by

Kelechukwu Favour(https://dev.to/nulfacedesigner)

GitHub: https://github.com/im-kaycee

Why I Stopped Flying Blind After Deploying My Side Projects

Kelechukwu Amadi-Keke — Tue, 02 Jun 2026 09:27:52 +0000

Introduction

For a long time, I treated deployment like a finish line.

I’d spend weeks locked in a room building a project, finally push it to production, shoot the link to a few friends, and immediately start brainstorming the next idea. Job done, right?

Except it wasn’t. The moment a project went live, it essentially entered a black box. I had no idea what was actually happening inside the code once it hit the wild. Were people clicking around? Which features did they actually care about? Was the API dragging its feet, or worse, quietly crashing while I was asleep?

I had absolutely no clue. Now I know that's the wrong way to build a product.

The Blind Spot

The turning point came with a project that looked flawless from the outside. The landing page loaded fast, authentication was snappy, and everything seemed perfect. I had just built a tool that allows users find out where a picture was taken through GPS metadata and OCR-Geolocation.

But then a friend texted me to complain that his uploads were failing.

I was so confused, because it had worked the night before. It turned out a critical endpoint had been completely broken for three days. Because casual users don't track down your email to file a bug report—they just close the tab and never come back, I had been bleeding users without realizing it.

That was the moment it clicked: If your users are discovering your bugs before you do, you’re flying blind.

The 4 Questions Your App Needs to Answer

Once your code is live, you shouldn't have to guess about its health. You need real-time answers to four fundamental questions:

Is it even online? If your site goes down at 2:00 AM, do you find out via an automated alert, or do you wake up to an email from an annoyed user? Uptime monitoring isn't a luxury; it's a baseline.
Are people actually using it? Page views are a vanity metric. You need to know the narrative of your app: Which features are pulling weight, which pages are ghost towns, and where exactly are people getting frustrated and dropping off?
What's breaking right now? Again, silence does not mean success. Most users won't complain; they’ll just leave. If you aren't actively capturing stack traces and error logs, you're relying entirely on luck.
Is the API healthy? An API doesn't have to completely crash to be broken. If a database query bogs down and an endpoint takes eight seconds to respond, it's effectively dead to the user.

The Dashboard Fatigue (And Building observe)

Naturally, the playbook answer here is to go sign up for tools. You get an account for product analytics, another for uptime, a third for error tracking, and maybe a fourth for API metrics.

Before you know it, you’re drowning in tabs. I found myself constantly context-switching, jumping between four different dashboards just to get a basic pulse check on a simple side project. The data was there, but it was completely fragmented.

Eventually, I got tired of the friction and decided to build a solution for my own sanity: observe.

I didn't build it because the world desperately needed another developer dashboard. I built it because I wanted a single, unified view that instantly answered those four core questions without the overhead or cost. I was just tired of guessing.

Final Thoughts

We tend to celebrate the "ship it" moment, but deploying a project isn't the end of the narrative—it's just Chapter One.
The moment your app interacts with real users is when the real learning begins. If you can’t see what’s happening beneath the hood, you’re making engineering and product decisions in the dark. And in software, flying blind always ends up being incredibly expensive.

The Sustainability Question Around AI Models

Kelechukwu Amadi-Keke — Thu, 09 Oct 2025 15:37:29 +0000

There’s something about this AI wave that feels different from past tech cycles. The speed, the hype, the reach — it’s all unprecedented. But as everyone rushes to build, release, and integrate, I keep wondering: is any of this truly sustainable?

When we talk about “sustainability” in tech, the first thing that comes to mind is usually environmental impact — energy use, carbon footprint, resource consumption. But with AI, sustainability goes deeper. It’s not just about how much power these models consume, but about the ecosystem that keeps them alive: compute, capital, and control. How much longer will AI tools be free/affordable?

The Cost of Intelligence

Someone in a discussion I had recently said something that’s really true: “These models are energy-intensive, and the current pricing structure isn’t sustainable.”

That line stuck with me. Because when you look at the sheer scale of what it takes to run systems like GPT, Claude, or Gemini, it’s staggering. These aren’t static models sitting quietly in a data center. Every query, every API call, every chat or image generation spins up thousands of GPUs burning power at an industrial scale.

It’s not just a matter of hardware — it’s the economics behind it. AI companies are in an arms race to make models smarter, faster, and more accessible, but each step up comes with exponential cost. Someone, somewhere, is paying that bill. Right now, it’s venture-backed firms and hyperscalers. But for how long?

The Capitalist Engine Behind “Open” AI

Others in that same conversation pointed to what’s maybe the less visible issue — the capitalist structure of modern tech. The people building the most powerful AI tools also own the platforms that distribute them, the servers that host them, and the companies that profit from their use.

It’s a closed loop — and it’s hard to imagine true openness inside that.

Even the supposedly “open” frontier models depend on infrastructure that’s owned by the same few companies. You can fork the code, train a small version, or deploy a fine-tuned variant — but in the end, you’re still renting your compute from the same giants who built the original models.

It makes you wonder whether this ecosystem is designed for democratization or for deeper dependency.

A Possible Shift: Self-hosted and Smaller

That’s why I find the rise of self-hosted models so interesting.

Developers and organizations are beginning to realize they don’t always need a massive, general-purpose model. For many tasks, a small, domain-specific model is enough — and it can run locally, without cloud APIs or recurring costs.

The tools are improving too. Frameworks like Ollama, vLLM, and Hugging Face’s inference tools are making it surprisingly easy to spin up your own LLM. You can fine-tune, host, and serve it privately.

This shift feels like a quiet rebellion — not against AI itself, but against its centralization. It’s a movement back toward autonomy.

And in that sense, it reminds me of the early days of open-source software — when people built because they could, not because it was profitable.

The Rise of Open and Chinese Models

Another recurring point in these conversations is the growing presence of Chinese models and open alternatives.

It’s not just diversity for diversity’s sake. It’s competition. Models like Yi, Qwen, and DeepSeek are advancing rapidly, and they’re breaking the Western monopoly over AI capability.

That shift could be healthy for the industry. It introduces pressure — on pricing, access, and innovation. It forces transparency and keeps the power balance in check.

In the long run, the end users — the developers, creators, and small startups — benefit from that competition. When there’s more choice, there’s more room for sustainability.

The Quiet Dependency No One’s Talking About

But there’s another kind of sustainability we don’t talk about enough — workflow dependence.

We’re entering a phase where an entire generation of developers is being shaped by AI-assisted tools. Things like Copilot, Replit AI, or N8N make development smoother, faster, and more enjoyable. They reduce friction and lower the barrier to entry.

But they also shift ownership.

When your entire workflow — your automation, your code generation, your pipelines — lives inside a closed ecosystem, you’re not working independently. You’re working inside a subscription model that can change, limit, or lock your access at any time.

Take N8N for example. It’s one of the most exciting no-code automation tools out there, but it’s slowly drifting toward paywall-based limitations. You can self-host it, yes, but the message is clear: freedom is available, but convenience costs money.

That’s the new dependency — not on a single model, but on the infrastructure of convenience.

Power, Cost, and Ownership

When we talk about sustainability in AI, we often focus on energy usage or financial viability. But maybe the real sustainability question is about ownership.

Who owns the models?
Who owns the pipelines?
Who owns the tools we use to create?

Because if the answer to all three is “someone else,” then what we’re building isn’t a sustainable ecosystem. It’s a rental economy disguised as innovation. And if the majority of students, developers and other professionals are hooked on these tools that have suddenly been made expensive, we might be looking at the new “white gold”.

The future we seem to be moving toward is one where access replaces ownership, convenience replaces control, and automation replaces understanding. And maybe that’s fine for some — but it shouldn’t be the only path forward.

Where we go from here

There’s still hope in the small things. The open-source communities building local models. The engineers writing papers outside corporate labs. The creators pushing for smaller, decentralized systems that can thrive independently.

That’s where sustainability might actually live — not in the biggest data centers or the most powerful models, but in the ability to build, host, and maintain tools on our own terms.

AI doesn’t have to be unsustainable. But it does need to evolve beyond this cycle of scale and dependency. Otherwise, we’ll wake up one day surrounded by incredible tools — none of which we actually own or understand.

And that’s not intelligence. That’s just another form of control.

I Failed My First Software Engineering Interview — And Here’s What I Learned

Kelechukwu Amadi-Keke — Sun, 28 Sep 2025 22:09:17 +0000

On Wednesday this week, I had my very first interview for an internship role at a software engineering company. Nerves were high, the stakes felt even higher, and I wasn’t sure what to expect.

I joined the call, introduced myself to the interviewer, and we got started. Things began smoothly… until they didn’t.

The Beginning

The interviewer started with the classic question: “Tell me about yourself.”

I had prepared well for this, so I answered confidently. We quickly moved on to my projects. He focused on my blockchain-based voting system and asked me to explain the architecture, data flow, and the essential parts of the app.

I walked him through the user interface, the smart contract functions, the backend, and how I used the MVT framework to tie it all together. Up to this point, everything felt great.

Mid-Interview

Then came the first curveball: “Why did you make XYZ design choice?”

I froze for a second. I knew that design had a flaw that would hurt performance in large-scale elections, but I hadn’t fixed it due to time constraints. I went into defensive mode, explained the flaw, and then talked about how I could fix it in future iterations. Luckily, that seemed to land well.

But then he followed with: “Your projects are cool, but your stack doesn’t really fit ours. How quickly can you adapt?”

This caught me off guard, but I shared how I had quickly adapted to Solidity when working on the voting system. That seemed to reassure him, and we moved to the final stage.

Interview End

The interviewer asked a few Python questions — my strongest language. I was ready… until he asked about two very basic concepts:

Asynchronous programming
Mutability of data structures

For reasons I still don’t understand, I blanked. I stuttered, gave answers that weren’t entirely wrong, but weren’t textbook definitions either.

I heard the sigh on the other end. In that moment, I knew the truth: I wasn’t getting the job.

Lessons Learned

This interview humbled me. It made me question whether I was truly good enough, whether I really knew my stuff, and whether I even belonged in this space.

But after reflecting, I realized a few things:

One interview isn’t the end. There will be many more, and better opportunities will come.
Interviews are a skill of their own. Preparing for interviews is almost like a full-time job, and fumbling doesn’t mean you’re not a good developer.
Failure is feedback. I now know exactly what to revise, and where to sharpen my knowledge.

Walking away, I didn’t get the offer — but I gained something else: clarity on what to improve, and confidence that the next time will be better.

How I Built a Blockchain Voting System (And What I Learned in 4 Days)

Kelechukwu Amadi-Keke — Sun, 21 Sep 2025 23:58:04 +0000

I was doomscrolling on YouTube sometime around December last year, when I came across a video by Cleo Abram where she explained why the United States did not make use of E-Voting systems to carry out the 2024 General Elections. While I can’t explain everything she said in the video, it got me thinking: “Can All These Issues Be Solved via Decentralization? ”. This motivated the application I built for my final year project.
For my final year project, I built a blockchain-based voting system that uses smart contracts to make elections transparent, tamper-resistant, and verifiable. The idea was simple: every vote is recorded on the blockchain, and no one can change the results once they’re in.

In this guide, I’ll walk you through what building such a system entails from a developer’s perspective — the architecture, the smart contract design, how the frontend interacts with the blockchain, and some of the challenges I faced along the way. I will not be speaking in any programming language specific terms, so as to give everyone an understanding of the system.

Problem Statement & Goals
The system was aimed at addressing two main issues. Simplicity for non-technical voters, and Security/Transparency of cast votes. This meant that the voting interface was made as easy as possible to understand, while votes were stored in the blockchain for security and displayed to users in real time for transparency.

High-Level Architecture
The system was designed with a semi-decentralized architecture in mind. Instead of a completely decentralized system, the registration of voters is done by an electoral commission, and login credentials given to the voters to login.

At its core, the voting system I built has three main parts:

The smart contract: this lives on the blockchain and is responsible for storing candidates, recording votes, and making sure no one can cheat (for example, by voting twice).
The frontend interface: this is what the voter sees: a simple page where they can connect their wallet, view candidates, and cast a vote.
The backend/indexer: this listens to blockchain events and stores them in a database so results can be shown quickly and cleanly, without querying the chain every time.

Here’s how they work together: the frontend lets a voter choose a candidate → their wallet signs the transaction → the smart contract records the vote on-chain → the results can be read either directly from the contract or through the backend, which makes things faster and easier to display.

I deliberately kept most of the logic on-chain so that security and transparency were guaranteed. The trade-off is that everything stored on the blockchain is public, but for the purposes of my project, that was acceptable since the main goal was to prove tamper-resistance and verifiability.

Smart Contract Design
The smart contract, written in Solidity, handled verification of authenticity of votes, vote storage and retrieval via some major functions. The first function was triggered when the backend sent the list of candidates to the contract for storage. This meant that only votes related to these candidates would be allowed. The second function handled vote validation and storage and was triggered when an event (Vote Casting) was triggered. This function retrieved the ID of the voter and the ID of the candidate that was voted for. This is then hashed to ensure it remains secure and is stored on the blockchain. The last function simply sends the number of votes cast for each candidate back to the backend for display on the frontend.

   function vote(uint256 candidateId) public {
        require(!hasVoted[msg.sender], "You have already voted.");
        require(candidates[candidateId].id == candidateId, "Invalid candidate.");

        candidates[candidateId].voteCount += 1;
        hasVoted[msg.sender] = true;

        emit VoteCasted(msg.sender, candidateId);
    }

Furthermore, some constraints were implemented on the contract. Only one vote can be cast per address (User). Casting more than one vote will trigger an error and reject the vote.

Development Workflow
Some of the tools used for development included Remix IDE for writing and deploying Solidity smart contracts to the Ganache Ethereum testnet which was used to simulate the blockchain network.
The frontend was developed using HTML, CSS and JavaScript and retrieved data from the backend via API requests. The backend was developed using the Django framework which allowed for ease of scale in the long term and communicated with the smart contract via web3.py. So it was essentially a middleman between the frontend and the smart contract.

Challenges Faced and Lessons Learned
Building this system was a roller-coaster especially because I had four days to do so and in the course of this, many challenges were faced and many lessons learned. Some of these challenges included the complexity of working with a new language as I hadn’t worked with Solidity prior to this. Although not a major issue, scalability of the system was another issue faced as the speed of the system reduced as more voters were added to the system but given the fact that this was just a prototype, it was negligible.
Gas fees and cost of transactions was not an issue given the fact that this was done on the Ganache testnet, but in a live system, gas optimization will definitely be something to look into.

What do you think? Is a semi-decentralized model the right approach for secure digital voting? Have you built something similar? I'd love to hear your thoughts in the comments!