Product
One system, built around the tenancy.
Not a short-let PMS with a longer date range bolted on. Everything hangs off the tenancy: the calendar bar, the lease, the cleaning task, the deposit, the emails. So nothing here has to be kept in step by hand.
Reservations & calendar
A calendar shaped like your business.
A mid-term year is a handful of long tenancies, not four hundred bookings. So every tenancy is one bar with the guest’s name on it, and a turnover is a gap you can see coming weeks before it happens.
Check-out is exclusive, and the handover is at noon
A tenancy that ends on the 30th frees the unit on the 30th. The calendar, the cleaning task and the next arrival all agree on that, because they read the same two dates rather than each keeping their own.
Blocks for the things that are not lets
Renovation, the owner staying, a unit held for a corporate account that has not signed yet. They occupy the calendar without pretending to be revenue.
One row, all the way through.
An enquiry from your website arrives as a row you can act on, not an email you have to re-type. Converting it keeps the guest, the dates and the correspondence attached.
- 1
Enquiry
Arrives from your website form or is logged by staff. Same row either way, resolved to the same guest record.
- 2
Tentative
Dates held while terms are agreed. Visible on the calendar as held, not as revenue.
- 3
Contract sent
The lease goes out when you press Send. Nothing before that moment touches the tenant.
- 4
Confirmed
Signed and countersigned. The dates are blocked everywhere and the cleaning tasks exist.
- 5
Checked in → out
The operations board takes over. The tenancy ends on its end date, exclusive, at noon.
One record per unit, and it is the only one.
Not a listing in the PMS, a folder of photographs on a laptop, and a description somebody pasted into the website three years ago.
The editor is one page, not nine tabs
Details, photos, content, pricing and publishing. Everything about a unit is reachable without leaving the unit, because the question you are usually answering (“what does this place cost and what is in it”) spans all five.
Photographs are processed once
Upload the file your photographer sent. It is resized into a thumbnail, a regular, a large and the original, and your website asks for whichever it needs. Nobody opens an image editor and nobody ships a four-megabyte JPEG to a phone.
Descriptions are plain text on purpose
The website renders them as text, so the editor emits text: paragraphs, undo, and nothing that can inject a stray tag into a customer’s page. Where HTML is genuinely wanted there is a different editor, and the difference is deliberate.
Four publishing states, not a checkbox
Draft, published, unlisted and inactive. A unit can exist in the system, be bookable, and not appear on the website, which is what a corporate hold or a unit under renovation needs.
Tenancy contracts
The lease is part of the software.
Not a Word file on someone’s desktop, not a DocuSign subscription billed separately, not a photograph of a signature in an inbox. The agreement is drafted from the reservation, signed in the browser, and filed against the tenancy it belongs to.
Your template, not ours
You bring the lease your lawyer wrote. It becomes a template with fields the reservation fills in: names, dates, rent, deposit, the unit and its address. We have no opinions about your clauses.
Sent only when you say so
Nothing leaves the building without an explicit Send. Changing a status, fixing a typo, correcting a date. None of it can email a tenant by itself, and that rule lives in the product rather than in a policy.
Signed in a browser
The tenant opens a link, reads the agreement, signs. No account, no app, no PDF round-trip. It works on the phone they read the link on.
The part that matters eleven months later.
A signature is easy. What a deposit dispute needs is proof of who signed what, when, and that the document has not changed since. That is the part a Word file and an email thread cannot give you.
Every agreement carries its own signing record, kept for as long as you keep the tenancy and exportable as a file you can hand to anyone.
Recorded on every signature
-
Who signed
Name and email, verified by the link only they received
-
When
Timestamp of every view, every field completed, and the signature itself
-
From where
IP address and user agent at the moment of signing
-
What exactly
A hash of the document as signed, so a later edit is provable
-
Countersignature
Yours, applied and recorded the same way
A contract is never just “out there somewhere”.
You can see, for every tenancy, exactly where the paperwork is. That is the difference between chasing and knowing.
Draft
Being written. Nobody has seen it.
Sent
With the tenant, unopened or unsigned.
Signed
Signed, countersigned, filed.
Declined
They said no, and it is recorded.
The fastest way to know whether this works for you is to watch your own agreement become a template. That is most of what a demo is.
Bring one of your leasesGuest email
Sent once. Recorded forever.
The failure mode of automated guest email is not that it fails to send. It is that it sends twice, or sends to somebody whose booking was cancelled an hour ago, under your name.
At most once, per trigger
Every automated message is keyed to the reservation and the trigger that sent it. Re-running, retrying, restarting, editing the reservation: none of it can produce a second copy. The log is what makes that true, rather than a convention somebody follows.
The log is never pruned
“Did we send that?” is a question people ask about last year, usually while a deposit is being argued about. So the send log keeps everything: what went out, to whom, when, and which trigger produced it.
Your words, in two languages.
Each message is a template you edit, with the reservation’s own details filled in: the name, the dates, the address, the door code. English and Dutch, because half the people renting a furnished flat in Amsterdam would rather read the Dutch one.
- Booking confirmed When you confirm the reservation
- Payment reminder A set number of days before rent is due
- Arrival instructions Shortly before check-in: address, keys, access
- Checkout details Before the tenancy ends: times, keys, deposit
- Contract to sign When you press Send on the agreement
The rule underneath all of it
Outward actions need one explicit intent signal.
Publishing a listing, sending a contract, sending an email. Each one needs a person deciding to do it. Moving a reservation between statuses is a correction, and corrections must be free: fixing a mistyped status at 9pm cannot email a tenant. Nothing in Quarters reaches a tenant, a website or a public API as a side effect of somebody tidying up a record. It is the oldest rule in the system, and everything else is built not to break it.
Operations & teams
The board that replaces the shared spreadsheet.
Every mid-term operator has one: a sheet with the week’s handovers and cleanings, open in four tabs, edited by three people, and authoritative because nothing else is. This is that sheet, derived from the reservations instead of maintained beside them.
Derived, never maintained
There is no sync job building this board and nothing to fall out of date. It is computed from the reservations every time you open it, so a booking you changed a minute ago is already there, and a cleaning for a cancelled tenancy simply isn’t. The only thing stored is what you add on top: who is doing it, at what time, and the note about the key. Derive the facts, store the decisions.
Built for a phone in a stairwell
The row keeps its time and its assignee on a small screen, because those are the only two reasons a cleaner opens it. Identity on the first line, the controls on the second. Nothing is hidden behind a tap that has nowhere else to be.
Time is a decision, not a guess
Handover is noon by default, because that is what the tenancy says. When the real time differs (an early flight, a late key) you set it on the row and everyone downstream sees the real one.
Hand out a login without handing over the business.
Users are free on every plan, which is deliberate: software that charges per seat quietly encourages a shared password, and a shared password is the end of knowing who did anything.
The alternative is a WhatsApp group. Most operators send the rota by message because the software made a cleaner’s login cost money. Then the rota exists in two places, one of them is a chat history, and a booking that moves updates neither. In Quarters the whole cleaning team has accounts, sees only what they need, and reads a board that cannot disagree with the reservations, because it is derived from them.
-
Admin
Everything, including money, members and settings.
-
Operations
Reservations, guests, contracts, the ops board. Not billing, not members.
-
Cleaner
Today’s tasks, the address, the access notes. Not the rent, not the tenant file.
Custom roles and permission sets are set up with you on Enterprise. The three above cover most teams.
More than one company, one login
Operators who run two entities, say a management company and an owner vehicle, hold up to five under one account and switch between them. Nothing leaks across: a colleague in one is not a colleague in the other unless you say so.
Somebody else’s organisation returns 404
Not “access denied”, which confirms it exists. Reaching for a company you are not a member of gets you the same answer as reaching for one that does not exist, so the customer list is not discoverable by guessing.
Every change is attributed
Who changed what, and when, kept as a readable trail. Not for surveillance. For the Tuesday when a rate is wrong and the useful question is when it changed, not whose fault it is.
Website & API
Publish when you mean to.
Your website reads from Quarters through a public API. What it reads is a snapshot you froze on purpose, never the row you are halfway through editing.
Frozen
Everything about the listing
Title, description, photos, amenities, address, rates. Edit them for as long as you like: rewrite the description, swap the hero photograph, argue about the rent. Nothing reaches the public until you press Publish, and then all of it does at once.
Every published version is kept, so you can see what the website was showing on any given day. That is the answer to “we never advertised it at that price”.
Always live
Availability, and only availability
The one exception, and it is deliberate. A booking taken thirty seconds ago blocks those dates on your website immediately. No publish step, no cache to wait out, no nightly job.
Double-booking a nine-month tenancy is not a mistake you recover from with an apology email, so availability is the thing that is never allowed to be stale.
Small enough to read in a sitting.
Your site asks for listings, asks for a calendar, and posts enquiries back, whatever it happens to be built with. A contract or accounting system reads reservations and reports agreements. Signed webhooks tell all of them when something changed, so nobody polls.
OAuth client credentials, issued and revoked from your settings.
The API reference- GETEvery published listing, as frozen
/api/v1/listings - GETLive availability
/api/v1/listings/{id}/calendar - GETBookings, with guest, money and contract state
/api/v1/reservations - PUTA contract signed elsewhere, reported back
/api/v1/reservations/{id}/agreement - POSTYour booking form lands here
/api/v1/inquiries
Money in integer euro cents · dates YYYY-MM-DD · check-out exclusive
Signed webhooks, with a delivery log
Each delivery carries a signature computed from a secret only you and we hold, so your endpoint can prove the call came from us. Failed deliveries are visible and retryable rather than silently lost.
You are not locked into our website
There is no proprietary site builder here, and that is deliberate. Your website is yours: Svelte, WordPress, whatever a designer hands you. This end just has to be honest about what is published.
Exports that are not a support ticket
Reservations, contracts and the signing evidence, out to a file whenever you want them. Your data is not the thing keeping you here.
Four, besides the API.
This is the whole list. There is no partner marketplace and no directory of logos we have never tested against. What is here works, and what is not here is not here.
Guesty
One-way migration. Properties, photos, descriptions, rates, reservations and guests come across; you cancel afterwards.
SendGrid
Delivers guest email, invitations and password resets. Bounces and complaints come back so a dead address is visible.
Mollie
Takes your subscription payment by iDEAL or SEPA direct debit. It is not involved in your tenants’ rent.
S3-compatible storage
Any provider. Property photographs and generated documents live in your bucket if you would rather they did.
The absences that matter.
These are the ones people ask about, and each is a decision rather than a backlog item. Naming them is cheaper for both of us than you discovering them in week three.
Airbnb, Booking.com, Vrbo
No channel manager. Mid-term demand does not arrive through them, and building a mediocre one would be the largest thing in the product.
Nightly dynamic pricing
A monthly rate is negotiated once per tenancy. There is nothing to optimise hourly.
Accounting packages
No direct connection to Exact, Twinfield or Xero yet. Exports are CSV and JSON, which is what most bookkeepers actually want.
Smart locks
No integration. Access codes live as notes on the operations task, which is where the cleaner reads them anyway.
A listed Zapier app
Not yet. Zapier, Make and n8n connect today through webhooks and the public API, with a guide for each; what is missing is a one-click app in their directories.
A guest mobile app
Guests get email and a signing link. They are moving house, not collecting loyalty points.
AI assistant
An assistant you can actually let touch the data.
Most property software with AI in it can answer questions. The useful version does the work as well. Almost nobody ships that, because letting a model write to a live tenancy is only safe if the guardrails are real.
It sees exactly what you see
The assistant runs with your permissions, not above them. A cleaner asking it a question gets a cleaner’s answer. There is no back door where the AI knows more about the business than the person talking to it.
Every change stops at a gate
Reading is free. Writing is not. Before anything changes you get a card showing exactly what is about to happen: this reservation, these dates, this contract to this person. Nothing moves until you approve it.
And every change can be undone
Approved something you shouldn’t have? The thread keeps what it did and can put it back. The conversation is the audit trail, not a separate log you have to go and find.
The assistant is on every plan.
Things people actually ask it.
Not because they couldn’t find the page. Because typing the question is faster than remembering which of nine screens holds the answer.
“Which units are empty in March and what did they let for last year?”
“Send the arrival instructions for everyone checking in this week.”
“Tom is off Friday. Move his cleanings to Paul.”
“How much deposit are we holding right now, and for whom?”
“Draft the lease for the Oud-West enquiry on the usual terms.”
The honest part
What it will get wrong.
It will occasionally misread an ambiguous question, and it will sometimes propose a change that is not the one you meant. That is why the gate exists and why it is not optional. The design assumes the model is fallible rather than promising it is not.
What it won’t do is act without showing you first, exceed your permissions, or touch a tenant. Sending an email and sending a contract are outward actions, and outward actions need a person pressing the button. That rule predates the assistant, and the assistant gets no exemption from it.
See it against your own portfolio
Thirty minutes, your units, your contracts. If it is not a fit we’ll say so. We’d rather lose the trial than the reputation.
30 days free · no card required · cancel by closing the tab