All systems operational200+ sites we watch overReply in under 2h+54 9 11 7820-8554
App · Travel · In build

Forward your bookings, get your day hour by hour.

Intiner.ar is a travel app we are building: your bookings go in, and your day comes out hour by hour. You drop in the PDFs and emails your trip already has. It reads the flights and hotels, and asks only what changes the plan. Every suggestion says where it came from.

Tell us your goalVisit intiner.ar
Intiner.ar

No mark exists to show: none was supplied, and the design system does not draw one. Where a logo would go, the name is set in the display face.

Our role
Product design + build
Surfaces
Public site · web app · mobile · 20 emails
Stage
In build
Languages
Spanish / English
4
Formats in

PDF, forwarded email, screenshot or .ics file

5
Questions, asked once

They belong to your account, not to one trip

7
Days of forecast

Only what the weather service returns, never a guess

20
Emails along the way

Itinerary ready, flight change, trip finished and more

What it is

A plan you can follow, built from what you booked.

Intiner.ar turns the idea of a trip into a plan you can follow, in Spanish or English. You can start from just a destination and dates, or load everything you have booked: flights with layovers, hotels, transfers, activities, tickets. The app works out what each document is, when it happens and where it belongs in your day.

Its work starts once you have booked. Selling and comparing flights, hotels and packages stays with the sites that do it. Intiner.ar takes what you already have. It returns a coherent schedule, day by day and hour by hour, that fits around everything confirmed.

The product is built on one idea: everything is specific to you. A block cites the file it was read from, like "Booking-Miraflores.pdf". Or it cites the preference behind it, like "gluten-free and local food, ten minutes from the hotel". A recommendation that cannot explain itself is left out. The data follows the same rule. Forecasts cover only the seven days the weather API returns. Flight status is shown exactly as reported. A destination shows its real photo, or none.

Where it lives
WhereWhat
Public siteResponsive webHero, how it works, a sample day, loading your bookings, plans and footer. The main way in, with the ES/EN switch always visible in the bar and one dark section per page, near the close.
Web appDesktop-first, 238px sidebarMy trips · itinerary (day / map / documents) · load bookings · my travel profile · sign-up wizard · administration. The timeline is the main screen; everything else supports it, and there is one primary button per screen.
Mobile appiPhone, 390×844The same screens in one column with a tab bar of four destinations and bottom sheets in place of dialogs. Parity is a rule: a feature that exists on web and not on mobile is a bug, not a platform difference.
Transactional email20 self-contained HTML filesWelcome, verification, incomplete wizard, itinerary ready, flight change, payment failed, quota exhausted, account suspended, trip finished and the rest. Each one opens in a browser and pastes into any sending provider.
What it does

Four things it has to get right.

Each one is a product rule before it is a screen. Break it and you get an interface the product cannot support.

01

Bring what you already booked

Four formats in, one schedule out: PDF, a forwarded email, a screenshot, an .ics file. The system reads what each one is and keeps the link back to the file.

  • —Flights with layovers, hotels, transfers and tickets, sorted automatically
  • —Asks only the question that changes the plan: "the AR 1304 stops in Santiago, do you leave the airport?"
  • —Every block keeps its source document, so the itinerary can always say where a time came from
  • —Data read from a document is corrected in the block dialog, and you are told that editing it breaks the link to the file
02

Scheduling that holds

Six block types, and the system places each one itself. It never lets two of them start at the same time: a hard rule, not a warning.

  • —No two blocks share a start time: the field is marked, the first free slot is offered, and save stays disabled
  • —Placement by type: a hotel lands on its check-in day at 15:00, and a flight opens its day with the airport transfer before it
  • —Accepting a recommendation drops it into the real gap and the toast says where it landed: "17:00, in the day’s free slot"
  • —Between two blocks, a travel leg shows door-to-door time, distance, traffic and one alternative, and is left out when the routes API returns nothing
  • —A transfer or hotel booked after the itinerary exists is inserted where it belongs, without asking "which day?"
03

A profile that can explain itself

Five questions at sign-up: who you travel with, your pace, food restrictions, how much you walk and your daily budget. The answers belong to your account, not to one trip.

  • —Answers are saved once and feed every future recommendation; they are edited later in "my travel profile"
  • —Every suggestion cites the preference it came from; if it cannot, it is not shown
  • —Editable in place: days, day notes, activity titles and personal notes. Enter confirms, Escape reverts
  • —A destination with nothing loaded offers to build the day from the account’s preferences instead of showing an empty page
04

Live data, with its limits visible

Four external integrations, each wrapped in a component that shows its own provenance and its own failure state.

  • —Flight status with the old time struck through beside the new one, plus terminal, gate and belt, and always a freshness line. A status with no timestamp is worse than none
  • —A closed status vocabulary: on time, delayed, cancelled, gate changed, landed. No new labels get invented
  • —Weather only inside the seven days the API returns; outside it, a note. Never an average or a historical figure dressed as a forecast
  • —The destination photo is resolved once from the places API and stored in the product’s own database; the interface always reads the stored copy, and only an administrator can replace it
  • —Any integration is allowed to be missing: the piece shows its honest state and the rest of the itinerary keeps working
Our lab, your site

What it means for your site.

Two rules we bring to yours: ask visitors only what changes the answer, and show where every answer comes from. On Intiner.ar, that is one question: do you leave the airport on your layover? On your site, it can be a quote form that asks only what changes the price.

Styleguide and branding

Paper before screen. One blue for anything you can touch.

No logo was supplied and the system does not draw one. Everything else is a decision taken from the brief and written down next to its reason: the linen ground, the single action blue, the three status colours, the editorial serif. It is carried by 34 components across core, forms, travel and billing.

Palette

Paper 1

#FAF6EF

The ground under everything: a warm linen. There is no pure white and no cool grey anywhere in the system; cards sit one step lighter, on paper-0 #FFFDF9.

Ink 900

#15130F

Primary text and the one dark section a page is allowed. A toasted black rather than #000, so it belongs to the paper.

Azul 600

#1B4DE4

The action colour. Everything you can touch, the day number on the timeline, and the italic ".ar" that stands in for a logo.

Clay 600

#C2542B

Warm secondary: editorial emphasis, and the accent that marks accommodation blocks on the itinerary.

Moss 600

#2F7D53

Confirmed. A status colour only, never borrowed for decoration.

Amber 600

#A8760F

Missing a data point, and the admin spend meter above 70% of its quota.

Rust 600

#B3382C

Clash: two blocks fighting for the same hour. Also the meter above 90%.

These are Intiner.ar’s colours, printed here as documentation. Nothing on werun.dev is drawn from them.

Typefaces

Instrument Serif

Display and the wordmark

76 / 54 / 38 / 28px, leading 1.02 to 1.18, tracking negative throughout. A blue italic word is the only emphasis a headline may carry, and never twice in the same headline. It is a declared substitution: no brand font binaries were supplied, so all three families are Google Fonts stand-ins until they are not.

Public Sans

Interface and body

Titles at 24 / 19 / 16, body at 17 / 15 / 13. Sentence case everywhere: capitals appear in exactly two places, the 12px eyebrow at .09em tracking and the day divider’s date line.

DM Mono

Times, flight codes, distances and prices

13px with tabular-nums, so a column of departure times aligns down the page. Every numeric column in the admin screens uses it.

Named, not loaded: this page sets every family above in werun.dev’s own type.

The rules

The name stands in for the logo

No mark was supplied, so the system does not draw one. Where a logo would go, the name is set in Instrument Serif with ".ar" in blue italic; on blue, the italic turns clay. The assets folder is left deliberately empty with a written list of what is still owed: logo.svg and a dark-ground version, two or three destination photographs, and a proprietary icon set if one ever exists. Drawing a symbol nobody asked for would have been the quick answer and the wrong one.

#8C8474 is for fills and borders

It measures 3.65:1 on paper, so it fails at every size and every level of importance. Muted text uses ink-450 #6F6657, which clears 4.5:1 on all four paper tones; #8C8474 is kept for fills, borders and decorative icons. The rule exists because the data most often set too light is exactly the data the product is obliged to show: a flight’s freshness line, a struck-through departure time, the postal address in a marketing email’s footer.

A status colour carries a status

Moss, amber and rust mean confirmed, missing data and clash, and nothing else may borrow them. The vocabulary behind them is closed (confirmed, missing data, overlaps, suggested), so no state is ever carried by colour alone. In the bilingual build the semantic key stays in Spanish and a labels prop writes the visible text: passing the English string straight in would produce the right words and a neutral tone, which is the traffic light quietly going out.

Every card fits its box, and the box measures itself

The domain cards live in a 320px panel, a mobile sheet and a four-column grid, so the window’s width says nothing about the room they have. They degrade on their own width with container queries: below 380px an itinerary event moves its 64px time rail above the card, below 300px a flight card drops the drawn route and stacks the airport codes. Grids are written minmax(min(Npx,100%),1fr) because a hard minimum overflows the moment its container is narrower, and words never break: a title shrinks a step before it is cut letter by letter.

Stack

What it is built with.

Next.jsReactCSS custom propertiesContainer queriesEditor.jsLucideGoogle PlacesGoogle RoutesGoogle WeatherFlight status APIAnthropic APIHTML email

Every provider lives in an environment variable

No provider, key or model is written into the code, including the model that generates the itineraries: it is chosen by variable, so it can change without touching the app. That is a design decision as much as a backend one. The interface never names a provider or a model to a traveller, and API spend in the admin screens is grouped by service (generation, places, routes, weather, flight status) rather than by brand, so the screen stays correct the day a supplier changes.

Bilingual changed the shape of the components

Where a string is both a visible label and the key that picks a colour, the key stays in Spanish and a labels prop writes the text. And no prop is ever a function: these are client components, and a function does not cross the server/client boundary; it fails at runtime, not at compile time. So a trip card receives "8 days" already written rather than a number, the composer takes durations as a map rather than a formatter, and durations travel in minutes with the locale deciding how to print them.

The email heights are measured

Twenty sendable files, built the way mail clients demand rather than the way the web has got used to: nested presentation tables, every style inline, no JavaScript, no external sheets, no webfonts and no images at all. Georgia, Arial and Courier New stand in for the three families, and the tokens are inlined as literal hex because no mail client resolves custom properties. Each preview height was measured from the outer table at 640px rather than guessed, because an optimistic number crops the legal footer, which is the one part that cannot be missing.

One API, two loaders

The design system previews without a bundler; the app runs on Next.js with server rendering. Two components load the same thing differently on purpose: the icon wrapper reads Lucide’s geometry from a global here and imports from npm there, because during server rendering there is no window, and a server-drawn fallback against a client-drawn glyph is a hydration mismatch on every single icon. The public API and the markup are identical, so porting a change touches the loader and nothing else.

Building something that has to be honest about its data?

Tell us what it has to do and where the numbers actually come from. We’ll tell you what it takes and who does it.

No commitment. Just a conversation.
Intiner.ar questions