Hamhey

The challenge

Relocation fragments housing, documents, appointments and payments across disconnected services. Someone moving to a new country deals with landlords, offices, paperwork and payments at the same time, often in an unfamiliar language and system.

Each of those steps has its own service, and none of them knows about the others. The result is a stressful, manual project that the person moving has to coordinate alone.

What we were responsible for

We delivered the cross-platform product for AI-guided housing, documentation, appointment and payment journeys. Together those journeys form a settlement operating system: one place to move through the practical steps of settling in.

The apps are early-stage, and we present them that way. The evidence on this page is the existence of the live web, Android and iOS listings rather than usage figures.

How we approached it

AI guidance is useful in relocation because the questions are personal and the rules vary. A product like this has to turn that guidance into concrete journeys, such as finding housing, preparing documents, booking appointments and paying, rather than leaving the user with a chat transcript.

Working across multiple countries raises the stakes for structure. Journeys need to adapt to local requirements without becoming a separate app per market, which is where a shared cross-platform foundation and clear journey boundaries pay off.

Early-stage products also need room to change. The aim at this stage is a foundation the team can keep reshaping as it learns which journeys matter most.

What shipped

Early-stage Android and iOS applications plus the public product website.

What this case shows

If your product coordinates many services on someone's behalf, AI is most valuable when it ends in an action. The engineering work is connecting the guidance to journeys that actually get things done.

How the engagement runs

Every project, this one included, follows the same four beats. They keep the scope honest and the work visible.

1. T-0

   Fit and risk

   We clarify the goal, the constraints, the existing system, and the decision that matters most. If we are not the right team, we say so.

2. Week 1

   A bounded first milestone

   Agree on the outcome, what is excluded, who is working on it, and what evidence will count as done, before the scope grows.

3. Every week

   Make the work visible

   Repository access, working demos, written decisions, and a visible change log. New scope becomes an explicit tradeoff before we proceed.

4. Handover

   Leave the team ready to own it

   Code, accounts, documentation, and release knowledge stay with you. Ongoing support is optional and scoped before launch.