Skip to content
gposse
ESEN

← Back to workPersonal app · Design and development · 2026

Cerquita

A web app for long-distance couples that organizes everything around the next visit. It came from a problem of my own, and I designed and built it myself.

Try the demo ↗

---

role:
Design and development, end to end
for:
Long-distance couples
platform:
Web app, mobile first
year:
2026

---

cerquita.mp4

Long distance, a relationship is built visit by visit: how long until the next one, how to get there and what to do once you're together.

Where it came from

My girlfriend lives in Córdoba and I live in Buenos Aires. We organized ourselves with tools that weren't made for this: the expenses app capped entries per day, so on trips some expenses ended up in a notepad. The countdown lived in another app, and we sent each other a link to see the same one.

And it wasn't just us: a long-distance couple's planning gets split across chats, expense apps, calendars and loose links, and none of those tools belongs to both people.

The problem

First I separated our case from the general one. I listed what a long-distance couple sorts out for each visit: how long until they meet, how and when to travel, what to do, how to split costs and what to keep.

Other apps had plenty of features. The problem was having each task in a different place, in tools built for something else, and none of them knowing it was all for the same visit.

Design principles

We were the first users. I set three principles: adding something takes seconds; the emotional comes before the data; and no pressure, no streaks or nagging reminders.

I used the most demanding user as the reference: paper planner, everything written down. If the app lived up to that planner, it would work for any couple.

An app for certain moments

Using it, we saw that Cerquita doesn't get opened every day. It's used around each visit: to book a flight, split a cost or save a plan. So what matters is how long a task takes, more than how often it's opened.

Everything around the visit

The first version handled each task separately: places, expenses, trips and memories, each in its own tab. Every module worked, but the app repeated the original problem with better design. A heuristic review (Nielsen) scored it 24 out of 40, and the main finding was structural: the same visit was copied in four places that didn't know about each other. The date was on the home screen, the trip in another tab, the flight finder started in the wrong direction and a dated plan could sit in another city.

I reordered the product by moment instead of by data type. Before the visit: how we get there, what's left, what we'll do. During: the plans for those days and what we're spending. After: a memory, settling up and setting the next date. The same features, ordered by the question the couple asks at each stage.

Decisions

  1. 01

    The plan for the visit

    Below the countdown there's a short list, in order of need: how we get there, what's left, what we'll do and the visit's expenses. Each step shows where it stands and offers a single action. It answers what we used to ask each other in chat: is everything ready for Saturday? The countdown rolls in from zero and each step checks off when it's done, so you can tell it's getting closer without reading it.

  2. 02

    From weekend to flight in two steps

    The flight's dates and direction come from the visit: Cerquita knows who's flying, when each person gets off work and flags long weekends from public holidays. It opens the route's airline (JetSMART, for Córdoba – Buenos Aires) with the dates filled in. Price alerts aren't there yet, and the app says so.

  3. 03

    An expense, no forms

    During a visit nobody wants to fill in a form. From the plan, a shared expense asks only for the amount and who paid, splits it in half and files it under the visit. Treats are left out on purpose: they create no debt, so it isn't worth interrupting the moment to log them. For the odd case there's still the full form, with custom amounts or “My treat”.

  4. 04

    While we're together

    From the second day of a visit, the first version was already asking “When do we see each other again?”. Now the app knows we've arrived: the countdown switches to “We're together” and the plan shows what's on for those days.

  5. 05

    Closing the visit

    When it ends, the plan changes: save a memory from those days, settle up and set the next date. It's the most emotional moment in the app, and it gets the next visit started.

  6. 06

    Places for that trip

    To save a place, pasting the Maps link is enough: the app fills in the name, the area and the kind of plan. Saved places barely got used and filled up with duplicates. Now it filters by the visit's city and warns when a place is already saved, with the option to open the existing one.

  7. 07

    Notifications that came from use

    They weren't in the first version; I added them after using it. When one person adds something, the other finds out without checking. They're optional, and the app doesn't ask for permission as soon as you open it.

01 / 07 · The countdown and the plan for the visit. Public demo.

What doesn't work yet

Right now the app builds each visit from the date we set and the trip that matches it. If a visit has no trip, or two, it can't tell what to show. Next is letting you create the visit directly: the dates, the city and who's traveling.

Places no longer fills up with duplicates, but I don't know yet whether it gets used more. And I've only tested the redesign myself: my girlfriend still has to use it on her phone during a real visit.

Identity

Deep green for actions, a cream background, yellow for the next visit and pink for closing it, with a five-petal flower as the symbol. A serif with character for headings and copy written from the couple's side: “we” for the couple and “you” only for instructions to whoever is holding the phone.

Takeaways

  1. 01

    Order by moment, not by module

    The features were the same. The product changed once they were ordered by the question the couple asks before, during and after seeing each other.

  2. 02

    The flashiest feature wasn't the value

    “My treat” was what I showed most from the first version. It's a nice detail, but the value is in nothing about the visit being left loose.

  3. 03

    Removing steps beats adding features

    A flight with the dates filled in, or an expense that asks for two things, does more than any new screen. Following the couple's real flow and removing steps helped most.

  4. 04

    Your own problem comes with bias

    Designing for something you live through gives you empathy, but also bias. Reviewing the first version against heuristics, not just my own use, is what showed the visit was split in four.