I Started Building SpareIQ Months Ago and Never Finished It. Here Is What Happened When I Finally Did.
This is a submission for the GitHub Finish-Up-A-Thon Challenge
My dad was an auto mechanic and spare parts dealer for most of my childhood.
I watched customers walk into his shop every single day with the same problem. They needed a part but did not know what it was called. They would describe it by saying things like "the round rubber thing near the wheel that makes that sound" or "the metal piece that holds the side mirror." My dad always knew what they meant. But he was one person, and he could not always be there.
That image follows me for years.
When I started learning to code, I thought about building something for that problem. A platform for Nigerian auto parts shops where customers could search in the way they actually speak, not in the way an engineer would write a parts catalogue. I started it. I got a basic structure up. And then I stopped.
Life moved. I kept learning. The project sat there, half built, doing nothing.
The Finish-Up-A-Thon gave me a reason to go back.
What I Built
SpareIQ is an AI-powered spare parts inventory and finder platform built specifically for the Nigerian auto market.
The feature I am most proud of is the AI Part Finder. You open it and you type however you would naturally describe a part. In English or in Pidgin. Or in whatever words come to you. The AI identifies the technical name, categorises it, and searches the live inventory for matching results.
I typed "the thing wey dey stop my Toyota when I press the pedal" and it came back with Brake Pads.
Beyond the AI finder, SpareIQ has a public storefront with search and category filters, part detail pages, a protected shop owner dashboard, full inventory management with image uploads, and Firebase powering everything in real time.
🌐 Live site: https://spareiq.netlify.app
💻 GitHub: https://github.com/mudimurtala/spareiq
Demo
Here is a full walkthrough of SpareIQ in action:
If you want to try the AI finder yourself, go to spareiq.netlify.app and type:
"the thing wey dey stop my Toyota when I press the pedal"
Watch what happens.
The Comeback Story
When I came back to this project, I spent the first hour just clicking through it trying to understand what past-me had built.
Some things worked. The routing was there. Firebase was connected. Parts were showing on the page. But a lot of things were quietly broken in ways that would have embarrassed me if I had shown it to anyone.
The View Details button on every single part card did nothing. I first thought I could see soem errors and I isn't redirecting me to a wrong page, it just does nothing when I clicked on it. When I looked at the code, I found this sitting inside the button:
onClick={(e) => {
e.preventDefault();
}}
A prompt I made earlier had added that to prevent some imagined double-click issue and in doing so had silently cancelled every navigation attempt. I removed the line and the whole thing started working.
The dashboard had a sidebar on the overview page. But the moment you clicked into Inventory Management or Add New Part, the sidebar disappeared completely. I were stranded on a page with no way back to the dashboard except the browser back button. I created a reusable DashboardLayout component and wrapped every dashboard page with it.
The hero search on the homepage would take you to the Parts page but your search term vanished the moment you got there. The Parts page had no idea what you had typed. I added a URL query parameter so the search term travels with you and pre-fills the results.
Those were the fixes.
Then came the things I added.
The homepage was too tall. You had to scroll before you even saw a single part. I reduced the hero padding and the featured parts grid jumped into view immediately.
I added a Browse by Category section between the hero and the featured parts. Clickable cards, one for each category: Engine, Brakes, Electrical, Suspension, Body Parts, Cooling System. Each one filters the parts page when clicked.
I added a Why SpareIQ section with three columns explaining what makes the platform different. And I built a proper footer with contact details, quick links, and the copyright line that makes any website feel finished.
Before this challenge: I had broken buttons, disappearing navigation, a homepage that hid its own content.
After the challenge: I have a deployed product I would actually show someone.
My Experience with GitHub Copilot
I want to be honest about how I used GitHub Copilot because I think the honest version is more useful than the polished version.
GitHub Copilot did not build SpareIQ. I did. But it was the difference between building something in five days and building something in five weeks.
The way it actually worked was this: I would come to the project knowing what I wanted to build. I had the architecture in my head, the feature requirement was clear, the user experience I wanted was decided. Then I would write a detailed prompt, sometimes paragraph length, explaining the exact file, the exact behaviour, the stack constraints, the edge cases. Copilot would generate the code. I would read it, test it, and decide if it was right.
That last step is the important one. There were times Copilot generated code that compiled perfectly and looked completely reasonable but was subtly wrong. The e.preventDefault() bug I mentioned was not something Copilot introduced during the Finish-Up-A-Thon. It was something added months earlier during the original build and I had not caught it because I did not read carefully enough.
The lesson I keep learning is that AI tools make me faster but they do not replace my understanding. If you cannot read the code and know whether it is right, you will miss the quiet bugs.
One moment that impressed me was when I gave Copilot a large prompt to implement the DashboardLayout component and wrap all the dashboard pages. It generated the code, ran the build, caught a TypeScript error it had introduced, fixed it, ran the build again, and only stopped when it passed. I watched that loop happen without me doing anything. That kind of self-correction used to take me hours of debugging.
The AI Finder itself was the most interesting part to build. The first model I tried returned quota errors. Copilot helped me swap the entire request structure to a different provider model cleanly and quickly. When the inventory matching was returning wrong results because it was matching on category alone, I described the scoring system I wanted in plain words and Copilot implemented keyword extraction with weighted scoring that made the matching accurate.
Working with GitHub Copilot on this project felt like having a very fast contractor who needs precise instructions and cannot always be trusted without supervision. When I gave it clear direction, the output was excellent. When I was vague, the output was generic. The quality of what it built was almost entirely determined by the quality of what I asked for.
What SpareIQ Is Built With
- React 18
- TypeScript
- Tailwind CSS
- Vite
- React Router v6
- TanStack Query
- Firebase Auth and Firestore
- Cloudinary for image hosting
- OpenRouter API for AI model access
- Netlify for deployment
One Last Thing
I am a self-taught developer from Nigeria. I studied Microbiology at university and started coding because I wanted to solve problems I actually understood.
SpareIQ came from watching my dad talk to customers who could not name the part they needed and thinking there should be a better way.
Finishing it felt like closing a loop that had been open for a long time.
If you have your own half-built thing sitting somewhere, I hope this is the nudge to go back to it.
Top comments (0)