Building the search behind Badilk

Badilk started with a simple idea: search for your phone, see which spare parts fit it. The hard part wasn't the app. It was the data behind it — where do we even get accurate information about which parts fit which phone?

There's no ready-made database for this. No one publishes "this battery fits this phone model" in a clean, structured way. Most of the raw specs exist on sites like GSMArena, but scattered across thousands of pages, written for humans to read, not for software to process.

So before we could build the app, we had to build something that could read that data automatically, keep it updated, and not break every time the source website changed something small.

The problem with doing it once

My first instinct was to collect the data once and be done with it. That doesn't work, because new phones come out every week. A catalogue that isn't updated becomes outdated fast. So this had to be a system that runs continuously, not a one-time task.

That single fact changed everything about how I built it. A system that runs forever needs to handle failure gracefully. It needs to know when something's wrong and adjust, without a person watching it every day.

How it works, in plain terms

I built the system in a few clear parts:

• It doesn't move too fast. It slows itself down automatically if it notices errors or slow responses, instead of hammering the source website.
• It spreads its requests out, so it doesn't look like one aggressive source hitting the site over and over.
• It only re-checks what's likely to have changed, instead of re-reading everything from scratch every time. This alone cut the update time from hours to minutes.
• It remembers what it already knows, so it doesn't waste time re-fetching pages that haven't changed.
• It stops itself when something looks wrong. If the source website changes its layout and the data coming in suddenly looks broken, the system flags it instead of quietly saving bad data.

That last part came from experience. Early on, a small layout change on the source site went unnoticed for almost a day, and it took real effort to clean up afterward. That mistake is exactly why the system checks itself now.

Why this matters to the product

None of this is visible to someone using the Badilk app. What they see is a search that actually works, with current, accurate results. That's the whole goal — the work nobody sees is what makes the part everyone sees feel reliable.

On the backend side, once the data is stored, searching through it fast was its own challenge. People type phone names in different ways — partial names, typos, Arabic transliterations. Getting search results back quickly, even with a growing catalogue, took real optimization work on how the database indexes that text.

What I'd do differently

If I built this again, I'd design the safety checks first, not after something broke. That's usually how it goes — you don't know exactly what to protect against until you've been burned by it once. The system works well now, but it works well because of a specific list of things that went wrong first.

Haithem Nini is the Co-Founder & CTO of Badilk, a phone spare-parts compatibility platform for the Algerian and Arab market.