HireKita

Local service hiring often starts through referrals, social media posts, informal recommendations, or direct chat messages. That can work when the client already knows someone, but it becomes harder when people need to compare workers, understand availability, check credibility, and turn a conversation into an actual booking.

For clients, the main concern is trust. They need to know who the worker is, what service they offer, where they are located, and whether other people had a good experience with them. For workers, the challenge is visibility. A skilled local worker may depend on word of mouth but still need a clearer way to receive opportunities, present their service profile, and manage requests.

HireKita was built around that gap. We treated local service booking as a mobile-first workflow where discovery, trust signals, booking status, and feedback should be connected. The goal was not just to list workers, but to create a structured marketplace flow that helps both sides understand what is happening before, during, and after a booking.

The problem with informal service hiring is that important information is scattered. Worker details may live in a profile post, availability may be discussed in chat, location may be handled manually, and feedback may not be connected to the next client's decision. This makes the process harder to trust and harder to repeat.

A client may find a worker but still not know if the request is confirmed, pending, accepted, cancelled, or completed. A worker may receive inquiries but lose track of which ones became real bookings. When booking status is unclear, both sides have to reconstruct the process from messages instead of relying on a shared record.

That is why HireKita needed more than a search screen. It needed a marketplace workflow with user accounts, service profiles, job or booking records, review feedback, and location-aware discovery. The product problem was about trust and coordination, not only browsing.

HireKita gives local service hiring a structured mobile experience. Clients can discover service workers, view profile information, create service requests or bookings, and track the status of the interaction. Workers can present their service profile and manage opportunities through the app instead of depending only on scattered chat conversations.

The system uses job, booking, and review records to make the flow easier to follow. A service request becomes something the system can track. A booking can move through visible states. A completed interaction can produce review feedback that becomes part of the trust layer for future clients.

Map-supported discovery also makes the product more practical for local services. Location matters when the service depends on distance, availability, and whether the worker can reasonably reach the client. HireKita uses mobile and map-centered design to keep the product grounded in how local services are actually found and booked.

HireKita was a four-member group project, and I served as the lead developer. My role was to guide the technical structure of the app, help shape the product workflow, and implement most of the core mobile system. I treated the project as a working marketplace MVP rather than just a set of Android screens.

I handled major parts of the original Android implementation, including Java-based views, XML layouts, Material Components, navigation flows, model handling, networking structure, and integration with Supabase. I later led the migration direction into Kotlin Multiplatform and Compose Multiplatform, moving the product toward shared UI, shared business logic, and a more modern cross-platform foundation.

Because the project involved multiple contributors, I also helped keep the system direction consistent. The important task was making sure profiles, jobs, bookings, reviews, sessions, and map features worked together as one product flow. My contribution was both technical and architectural: I built much of the app, modernized the stack, and kept the implementation aligned with the marketplace workflow we wanted to present.

The workflow begins when a user registers or signs in. From there, the app supports the marketplace relationship between clients and service workers. A client can browse service options, inspect worker information, and move from discovery into a service request or booking. The goal is to make the first step more structured than simply messaging someone without context.

Once a request becomes a booking record, the interaction can be tracked through the system. Instead of leaving the status hidden inside a conversation, the app can represent the booking as pending, accepted, active, completed, cancelled, or ready for review depending on the flow. Those states help both sides understand what has happened and what should happen next.

After the service interaction, review feedback closes the trust loop. Reviews give future clients another signal when choosing a worker, while workers gain a more visible service history. That makes HireKita more than a directory; it becomes a mobile workflow for discovery, booking, status tracking, and reputation.

HireKita began as a native Android app using Java, XML-based Android Views, and Material Components. That first build proved the marketplace flow on mobile: navigation, form flows, profile screens, booking interactions, and map-supported discovery.

The current implementation is migrated to Kotlin Multiplatform and Compose Multiplatform. Compose Multiplatform provides the declarative UI layer, while Kotlin Multiplatform gives the project a shared foundation for models, business rules, networking, serialization, and platform-specific hooks where needed. Material 3 keeps the UI aligned with a modern Compose stack.

Supabase provides the backend foundation for authentication and PostgreSQL-backed marketplace records. The app uses structured data models for users, service workers, jobs, bookings, and reviews. This keeps the marketplace flow connected: account identity, worker profile data, service requests, booking states, and review feedback all belong to the same backend model.

For communication with backend services, the current stack uses Kotlin-first networking and data handling through Ktor Client, Kotlinx Serialization, and coroutines. DataStore and Jetpack Security support safer local session handling, while map integration keeps local discovery central to the service-booking experience.

The architecture follows the product logic. The shared Kotlin layer keeps marketplace rules reusable, Supabase preserves the records and authentication state, and the Compose Multiplatform UI makes the product easier to carry beyond the original Android-only build. That migration makes HireKita stronger than a static prototype because both the product workflow and the technical foundation are designed for continued expansion.

HireKita is a working MVP built as a four-member group project and modernized through a Kotlin Multiplatform and Compose Multiplatform migration. It is not positioned as a production marketplace with live public adoption yet, but it has the core product structure needed to demonstrate the local-services workflow: authentication, mobile screens, marketplace records, bookings, reviews, networking, and map-supported discovery.

At this stage, the project is strongest as a functional proof of concept for a local-services marketplace and as a modernization story. It shows how the client-worker relationship can be modeled through mobile screens and backend records, and how the original Android implementation can evolve into a shared Kotlin architecture without losing the product workflow.

The next level of maturity would involve usability testing with real clients and workers, tightening service categories, improving booking-state rules, adding stronger moderation or admin controls, and validating whether the workflow fits how local service workers actually manage availability and requests.

The main outcome of HireKita is a working marketplace MVP that connects a mobile client experience with a Supabase-backed model and a modern Kotlin Multiplatform foundation. The project moves beyond a simple listing app by including authentication, service records, booking flow, review feedback, session handling, and map-supported discovery.

From an engineering perspective, the project strengthened my experience with native Android development, Java/XML migration, Compose Multiplatform, Kotlin Multiplatform, Kotlin-first networking, secure session storage, and backend-connected mobile workflows. It also gave me practice in thinking through how mobile screens map to real data states, not just visual navigation.

From a product perspective, HireKita proved that local service discovery needs more than search. A useful marketplace has to support trust, status, and repeatable interactions. The MVP gives that idea a working structure that can be tested, improved, and expanded with real user feedback.

HireKita taught me that trust in a marketplace is built through many small product details. Profiles, reviews, booking states, location, session reliability, and clear navigation all affect whether a client feels confident enough to request a service and whether a worker feels the platform is worth using.

It also taught me that mobile apps have a different reliability standard. Users expect the app to remember them, recover sessions properly, load information quickly, and keep the workflow understandable even on smaller screens or unstable connections. That made authentication, token handling, networking, and state management feel like product concerns, not only technical tasks.

As the lead developer in a group project, I also learned how important it is to keep implementation aligned with the product story. A marketplace can easily become a collection of disconnected screens. The challenge was to make the app feel like one coherent system where discovery leads to booking, booking leads to status, and status leads to trust.