Product

Building SiraHub: An Android Job Marketplace for Ethiopia

Why generic job apps fit the local market poorly, and the product and engineering decisions behind SiraHub.

SiraHub started from a simple observation: the job-search apps most Ethiopians end up using were not built for this market. Salary fields default to dollars. Filters assume job categories that do not match how hiring works locally. And most apps treat "job seeker" as a single type of user, when someone applying for a retail role and someone applying for a senior developer role want very different things. This article explains the product and engineering decisions behind SiraHub, an Android job marketplace available on Google Play.

Start with both sides of the market

A marketplace only works if both sides get something better than what they already have.

  • For employers, that meant one dashboard where posting a role, reviewing applicants and managing a company profile happen together, without sifting through unrelated applications.
  • For job seekers, it meant salary ranges in Ethiopian Birr from the start, skills-based matching instead of keyword guessing, and a one-tap application flow built around uploading a CV once and reusing it.

Each feature had to pass one test: does it remove friction that people currently accept as normal?

Why native Android

We built SiraHub as a native Kotlin app rather than a cross-platform wrapper, mainly for performance on the mid-range Android phones most users carry. Many hybrid frameworks add overhead that shows up as lag on exactly those devices. Designing for modest hardware and variable networks also shaped smaller choices: lightweight screens, careful image sizes and not loading more data than the screen needs.

Why Firebase

Firebase and Firestore handle authentication, real-time job listings and chat between employers and applicants. For a small team shipping a mobile-first product, managed services meant we could spend our time on the product rather than on servers. The trade-offs, including cost behaviour and vendor lock-in, are covered in Firebase or MySQL?

Security rules took more iteration than the UI

Because the app talks to Firestore directly, security rules decide who can read and write what. They make sure a seeker cannot read another seeker's private conversation and an employer cannot edit a job post that is not theirs. Getting them right took more iteration than the interface did.

  • Read does not imply write. Permission to read a message should not automatically allow sending one.
  • Ownership checks matter. Every edit rule should verify that the signed-in user owns the document.
  • Use server timestamps. Relying on device clocks can quietly reorder a conversation and confuse users.
  • Test as the wrong user. Check every rule with accounts that should be denied, not only those that should succeed.

AI where it removes work

SiraHub uses Gemini AI for three specific things: parsing an uploaded CV into structured fields, suggesting relevant jobs from a seeker's profile and handling looser, natural search queries instead of forcing exact keywords. The goal was not to add AI for its own sake. It is used only where it removes effort that would otherwise fall on the user, such as retyping CV details the app can already read.

Designing for the local market

  • Birr first: salary ranges are shown in Ethiopian Birr rather than converted from dollars.
  • Different users, different needs: flows that work for a retail applicant do not need to burden a software engineer, and vice versa.
  • Local payment methods: where employers pay for job posts, local rails such as TeleBirr and bank transfer matter more than card checkout. See Digital Payments on Ethiopian Websites.

Where it stands now

SiraHub is live on Google Play, with job seekers and employers posting real listings. It is under active development: push notifications for new matching jobs, a more refined employer dashboard and expanded AI-assisted matching are in progress. Most of what has shipped came from watching how people use the app and fixing the friction that showed up, rather than building features speculatively.

What we would tell another team

  1. Pick one narrow audience and make it clearly better for them.
  2. Build for the phones and networks your users actually have.
  3. Treat security rules and permissions as a product feature, and test them adversarially.
  4. Add AI only where it measurably removes work.
  5. Let real usage, not assumptions, set the roadmap.

Read more about the app on the SiraHub page.

Found a mistake or an outdated detail? Email contact@abtech.com.et and we will review it. See our Editorial Policy.