The cheapest room is rarely the cheapest trip. In a Nigerian university town like Ekpoma, a 12,000 room 19 minutes out can beat a 22,000 one next to the venue. It can also losr, once transport and time are counted.

Booking sites show the nightly rate and a distance. They don't add up the taxi fares, the travel time, or the risk of arriving late to the thing you came for. Verified listings are also scarce outside big cities, so travellers end up guessing from a few photos and a phone number.

One conversation, not a form. You describe the trip in your own words and can add, correct or ask anything at any point. Not4 asks only for what's still missing, one thing at a time, and never invents date.

Real stays for any town. It finds places near the venue on OpenStreetMap, times each ride on real roads, and searches the web for prices. A price is kept only if the page is came from was actually opened; anything estimated says so.

Stays ranked on total cost. A compact table: the nightly rate, the ride and time to the venue, the total ranks them, and how much more each costs than the best fit. Stays over budget drop below the rest.

A plan built around the real event. It works back from the event time and the journey, so a 13-hour bus ride means arriving the day before. What it had to assume is listed, and "add lunch with a client at 12:30" changes the plan.

Everything after the plan. Each trip has a page in Journals with its facts, plan, directions and reminders. Reminders go by push and email, with Google Calendar sync and a calendar link that works in any calendar app.

I designed every surface in Paper before writing code: several directions per screen, one chosen, then drawn at real sizes. Three decisions shaped the whole thing.

A conversation, not a form. The product is built around saying the trip once. Everything happens in one calm reading column: you type, and stays and the plan arrive inline as answers. Nothing closes or locks, so changing the trip is just another message.

Show the reasoning, not just the answer. Trust is the hard part when listings are thin, so the design puts the working on screen. Total cost is the number that ranks stays, set beside the rate, ride and time that make it up. Every price says where it came from, and the plan lists what it assumed so you can correct it.

Quiet by default, loud only for decisions. A warm, document-like look with one accent: plum marks the choices you make, yellow highlights the best fit, everything else is ink on white. A few type sizes and one shared set of components keep every screen consistent, accessible and light enough for modest phones.

I rebuilt the chat after using it. The first version was a fixed run of questions. It planned around a placeholder date when you hadn't given one, put a 6-hour bus ride on the morning of a 2pm meeting, and closed the chat once stays were shown. I replaced it with a conversation, and replaced the planner's fixed templates with one that works from the real event time and journey.

The ranking is plain arithmetic, not AI. The scoring engine is a set of pure Go functions that add up rate, transport and time, weighted by your preference. It is tested in isolation, so the same answers always give the same ranking, and every number on screen can be explained.

The model plans; the code sets the rules. The language model runs the conversation with five tools: record a fact, search stays, choose one, build the plan, edit it. The code refuses a past date, won't plan without a date, keeps no price without a source, and saves nothing from a turn that fails. Conversations aren't stored at OpenAI, and every call is metered against its trip.

Real data without a booking API. Booking.com and Amadeus both require business verification, so stays come from OpenStreetMap, with prices from a web search that must cite a page it opened. Each search is cached per venue and shared by everyone going there. Google Maps can replace OpenStreetMap with one API key.

Tests written against the product spec, not the code. Every test traces to a goal or a step in the written product requirements. That's 303 Go tests and 311 frontend tests, including whole conversations driven through the real tools by a scripted planner.

Accessible and light by default. Keyboard and screen-reader support, checked contrast, reduced motion respected, and a layout that works on a phone first. It's built to run well on modest phones and networks.

Hardened before launch. A security review led to concrete changes: sign-in sessions are stored only as hashes, so a leaked database can't be used to log in; the endpoints that call the language model are rate-limited and size-capped, since every message costs money; push notifications only go to real browser push services; and trips are granted only when a payment actually covers the pack. One free trip stays one per person, even across a deleted and re-created account.

Designed and built in three weeks, and live at notefour.xyz. One sentence in, it finds real stays near the venue in any town, ranks them on what they really cost, and plans the trip around the event, with reminders to follow.