Building a Student Accommodation Management System: Beds, Terms, Bookings

A student accommodation management system sells beds for a fixed term, usually an academic year, rather than open-ended monthly tenancies. Its core is bed inventory, term-based contracts, a booking hold so two students never pay for one bed, instalment billing and scheduled jobs. PropDesk, the property platform RAITHub built, runs 5 daily jobs and 1,024 tests; student housing adapts those patterns.

This guide is for purpose-built student accommodation (PBSA) operators, university housing teams and PropTech founders in the UK, US, EU, Australia, the Gulf and Asia who are deciding whether to build. RAITHub has not shipped a student accommodation product. PropDesk is a property management platform for landlords; the student-housing design below is engineering guidance adapted from its leases, payments and scheduled jobs. Legal points are general information: confirm the current rule with your adviser.

What does a student accommodation management system need to do?

It has to run a yearly sales cycle, not a monthly rental cycle. Most beds are booked in a few busy months, contracts start and end on term dates, and next year's rebooking opens while this year's students are still in residence. That shape drives every module.

Module	What it does	Why student housing is different
Bed inventory	Buildings, flats, rooms, beds and room types	Students book a bed or a room type, often in a cluster flat shared with strangers
Term options	Contract lengths and prices per room type	The same bed may be sold as a full academic year, a shorter term or a summer stay
Booking and hold	Reserves a bed while the student pays	Peak demand means many students chasing the same room type at once
Contracts	Agreement per student, per term	Fixed start and end dates, sometimes a guarantor, sometimes paid in full upfront
Instalments	Splits the term fee into scheduled payments	Often aligned to terms or loan payments rather than calendar months
Arrivals and departures	Check-in, keys, inventory, check-out	Hundreds of arrivals in the same week
Room swaps	Moves a student to another bed	Common in the first weeks; must never leave a bed double-booked
Rebooking	Offers current residents next year's beds	Runs while the current contracts are live
Maintenance and notices	Requests, building announcements	Same as any property product, at higher volume

Should we buy student housing software or build our own?

Buy if you run buildings the way most operators do; established platforms already cover bookings, contracts and rebooking. StarRez, for example, lists student property management (PBSA) and higher education among the sectors it serves, and says it serves 1,100+ institutions and 2,000+ properties worldwide (StarRez). Entrata's student housing product lists roommate matching, bulk unit assignment and automated renewals (Entrata: student). Both checked 30 September 2026. Build when the software is your product, or when your sales model is the thing no product supports.

Your situation	Usually the better fit	Why
One or a few buildings, annual contracts, standard room types	Buy	This is the core use case of every student housing platform
A university housing office with existing student systems	Buy, and integrate	Integration with student records is the hard part, and vendors have done it before
Mixed terms, summer lets and short stays in the same beds	Build, or buy and test the edge cases hard	Selling one bed several ways without overlap is where tools strain
A booking-led brand where the purchase journey is the product	Build the booking layer on top of a platform, or build outright	You control the experience and conversion
You are selling student housing software to operators	Build	The software is the product

If you are still weighing the wider build-or-buy question, the property management software development guide covers the ledger and role design that every property product shares.

How do you model beds, rooms and academic-year contracts?

Model the bed as the thing sold, the term option as the thing priced, and the booking as a bed plus a date range. A term option is a room type, a date range and a price: for example "Ensuite, 2027/28, 44 weeks, GBP 205 a week". Copy the dates onto the booking when it is made, so a later change to the term option never silently moves a signed contract.

Prices in these examples are illustrative, not market data. A UK operator might price in GBP per week, an Australian one in AUD per week, a US one in USD per semester; store the amount in integer minor units with its currency, and never assume one pricing unit.

CREATE EXTENSION IF NOT EXISTS btree_gist;

-- A contract length and price for a room type, e.g. 'Ensuite, 2027/28, 44 weeks'.
CREATE TABLE term_option (
  id           uuid PRIMARY KEY,
  room_type_id uuid NOT NULL REFERENCES room_type(id),
  label        text NOT NULL,
  during       daterange NOT NULL,      -- [start, end): the end date is free again
  price_cents  bigint NOT NULL CHECK (price_cents > 0),
  currency     char(3) NOT NULL          -- 'GBP', 'AUD', 'USD', 'EUR', 'SGD'
);

CREATE TABLE booking (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  bed_id          uuid NOT NULL REFERENCES bed(id),
  student_id      uuid NOT NULL REFERENCES student(id),
  term_option_id  uuid NOT NULL REFERENCES term_option(id),
  during          daterange NOT NULL,   -- copied from the term option at booking time
  status          text NOT NULL CHECK (status IN ('held', 'confirmed', 'cancelled', 'expired')),
  hold_expires_at timestamptz,
  -- Backstop: no two live bookings on one bed with overlapping dates.
  EXCLUDE USING GIST (bed_id WITH =, during WITH &&)
    WHERE (status IN ('held', 'confirmed'))
);

The exclusion constraint follows the room-reservation example in the PostgreSQL documentation, which uses btree_gist to combine an equality check with a date-overlap check (PostgreSQL: range types). Because it covers any overlap, a 44-week contract and a summer let on the same bed can coexist only if their dates genuinely do not touch.

How do I stop two students booking the same bed at the same time?

Hold the bed inside a database transaction that locks the bed's row with SELECT ... FOR UPDATE, re-checks availability, and inserts a hold with an expiry. A second request for the same bed waits at the lock, then sees the hold and is offered another bed. The student pays within the hold window, and a webhook turns the hold into a confirmed booking.

Written for this post as a minimal sketch, using node-postgres:

import type { PoolClient } from 'pg'

// Longer than the Stripe Checkout expiry below, so the session always dies first.
const HOLD_MINUTES = 35

export async function holdBed(db: PoolClient, bedId: string, studentId: string, termOptionId: string) {
  await db.query('BEGIN')
  try {
    // 1. Lock the bed. A concurrent request for this bed waits here until we finish.
    const bed = await db.query('SELECT id FROM bed WHERE id = $1 FOR UPDATE', [bedId])
    if (bed.rowCount === 0) throw new Error('bed not found')

    // 2. Expire stale holds on this bed, then check it is free for the term.
    await db.query(
      "UPDATE booking SET status = 'expired' " +
        "WHERE bed_id = $1 AND status = 'held' AND hold_expires_at < now()",
      [bedId],
    )
    const clash = await db.query(
      'SELECT 1 FROM booking b JOIN term_option t ON t.id = $2 ' +
        "WHERE b.bed_id = $1 AND b.status IN ('held', 'confirmed') AND b.during && t.during",
      [bedId, termOptionId],
    )
    if (clash.rowCount) {
      await db.query('ROLLBACK')
      return null // taken: offer another bed of the same room type
    }

    // 3. Place the hold with the term's dates copied onto the booking.
    const hold = await db.query(
      'INSERT INTO booking (bed_id, student_id, term_option_id, during, status, hold_expires_at) ' +
        "SELECT $1, $2, t.id, t.during, 'held', now() + make_interval(mins => $3) " +
        'FROM term_option t WHERE t.id = $4 RETURNING id, hold_expires_at',
      [bedId, studentId, HOLD_MINUTES, termOptionId],
    )
    await db.query('COMMIT')
    return hold.rows[0] as { id: string; hold_expires_at: Date }
  } catch (err) {
    await db.query('ROLLBACK')
    throw err
  }
}

The details that make it hold up in rebooking week:

• Match the hold to the payment page. Stripe Checkout's expires_at can be set from 30 minutes to 24 hours after the session is created, and defaults to 24 hours (Stripe: create a Checkout Session). A 24-hour default would lock a bed for a day for a student who closed the tab. Set the session to expire at 30 minutes and hold the bed for 35, so the payment page always closes before the hold does.
• Confirm from the webhook, not the redirect. On checkout.session.completed, confirm the booking if it is still held. If a slow webhook arrives after a sweep marked the hold expired, confirm it only if the bed is still free, and refund otherwise. That branch is rare, so it needs its own test. The online rent collection guide covers idempotent webhook handling.
• "Any bed of this type" is a queue. When the student picks a room type rather than a bed, choose a candidate bed with FOR UPDATE SKIP LOCKED so concurrent requests take different beds instead of queueing on one. The oversell prevention guide covers the same pattern for stock.
• The constraint is the last line. If a code path ever skips the lock, the exclusion constraint still rejects the overlapping insert. Test that by bypassing the function on purpose.

How should instalments and deposits work for term-based contracts?

Price the contract once, as a total for the term, then split it into scheduled instalments in integer minor units so the parts add back to the total. A 44-week contract at GBP 205 a week is GBP 9,020, or 902,000 pence; three instalments are 300,667, 300,667 and 300,666 pence. Generate the schedule when the booking is confirmed, and store each instalment with its due date.

// Split a term fee into n instalments; the first ones absorb the extra pence.
export function instalments(totalCents: number, n: number): number[] {
  if (!Number.isSafeInteger(totalCents) || totalCents <= 0 || !Number.isInteger(n) || n < 1) {
    throw new Error('invalid instalment plan')
  }
  const base = Math.floor(totalCents / n)
  const extra = totalCents - base * n
  return Array.from({ length: n }, (_, i) => base + (i < extra ? 1 : 0))
}

instalments(902_000, 3) // [300667, 300667, 300666]

On Stripe, instalments tied to term dates rarely fit a monthly subscription. Two simpler options: send one invoice per instalment on its due date from a scheduled job, or, for a yearly plan, anchor with billing_cycle_anchor_config, which accepts a month and day of month (Stripe: billing cycle). Stripe prorates to the second by default whenever a subscription changes mid-period (Stripe: prorations), so for a room swap mid-term, calculate the difference yourself by day and invoice it explicitly. The billing models guide explains when a subscription is the wrong tool.

Deposits, guarantors and upfront payment for students without a local guarantor all vary by country and by operator policy, and some carry legal rules about where money is held and when it is returned. Build them as configurable rules per property, and confirm the current rule with your adviser.

Which scheduled jobs does a student accommodation system need?

PropDesk runs 5 daily jobs: rent reminders, late fee assessment, lease expiry alerts, maintenance auto-closure and scheduled rent increases. A student system keeps the reminders, fees and expiry alerts, and adds jobs driven by the booking calendar. Every job must be safe to run twice, late, or after a missed day.

Job	Runs	What must hold if it runs twice or late
Expire stale holds	Every minute	Only holds past their expiry are released; a paid hold is never released
Instalment reminders and late fees	Daily (PropDesk pattern)	One reminder and at most one fee per instalment
Contract end and check-out prompts	Daily (PropDesk pattern)	A missed day still sends the prompt; departures are listed per building per day
Rebooking window	On configured dates	Current residents get their offer once, before the bed goes on general sale
Maintenance auto-closure	Daily (PropDesk pattern)	Never closes an urgent request
Unconfirmed arrival follow-up	Daily in arrivals week	Each late arrival is chased once a day, not once a run

Each row's right-hand column is the specification for that job's tests. Scheduled jobs run when nobody is watching, and in student housing they run hardest in the same few weeks every year.

Which roles and portals does student housing software need?

PropDesk's 4 roles map across, with two additions. PropDesk serves landlords, tenants, contractors and admins; the student-housing mapping below is guidance.

PropDesk role	Student housing equivalent	Sees and does
Landlord	Operator or housing officer	Buildings, beds, term options, bookings, arrears, arrivals
Tenant	Student	Own booking, contract, instalments, maintenance, notices
Contractor	Maintenance or cleaning team	Assigned jobs only
Admin	Platform admin	Users, settings, audit trail
(new)	Guarantor or parent	What the student and the agreement allow, and no more
(new)	University partner	Allocations into beds it has an agreement for, if your model includes one

A student may be under 18 at booking, and a guarantor's access must be explicit, never assumed. Put both in the permission matrix and test them; SaaS authorisation and RBAC design covers how. Deliver the student side as a responsive web app or PWA: it reaches every phone during arrivals week without an app-store release.

Which rules affect student accommodation software, and what should we confirm?

Housing rules decide some of your data model, so settle them before the build. RAITHub does not give legal advice; the table lists questions to take to your adviser, with one confirmed example from England.

Market	Question to confirm with your adviser	Why the software cares
UK (England)	Does any building count as an HMO, and does it need a licence?	Licence expiry and occupancy limits become data and alerts
UK	Will you join a code of practice for student accommodation?	Codes may set expectations for contracts, repairs and complaints that the workflow should record
US	Do you receive student records from a university partner?	Access, retention and sharing rules for that data
Australia	Which state's residential or boarding-house rules apply to each building?	Agreement types and notice periods differ by state
EU	What personal data do you collect from applicants, and on what basis?	ID documents and guarantor data need minimising and retention rules
Gulf and Asia	What tenancy registration or contract rules apply to shared or student housing?	Contract fields and registration steps

The England example: GOV.UK defines a house in multiple occupation as a property rented by at least 3 people who are not from 1 household and share facilities; a large HMO rented to 5 or more people needs a licence, valid for a maximum of 5 years (GOV.UK: HMO licensing). Whether a particular student building is treated this way depends on how it is owned and managed; confirm the current rule with your adviser. In the UK, the ANUK/Unipol National Codes are independent standards for student accommodation, and report over 400,000 bedrooms accredited (National Codes).

What does it cost to build, and how long does it take?

A focused first release, one audience and one money flow, typically takes 4 to 6 weeks at fixed scope with RAITHub. A student system with inventory, term options, holds, instalments, rebooking and portals is several releases. Time the first release to go live before your peak booking months, not during them. The real estate platform cost guide explains the cost drivers, and the MVP cost estimator gives a first range for your feature list.

How does working with a Dhaka team fit your booking season?

RAITHub works from Dhaka, UTC+6, with no daylight saving. UK teams get about 3 to 4 working hours of overlap and Central Europe 4 to 5; Dubai and Singapore about 7; Sydney 4 to 5. For US clients there is a daily 2-hour evening overlap, Dhaka 19:00 to 21:00, which is US East mornings. The working week is agreed per client. Plan a code freeze and extra monitoring for your peak booking weeks, whoever builds the system.

Why RAITHub for this

• Leases, payments and scheduled jobs are built and tested. PropDesk has Stripe rent collection, the lease lifecycle, maintenance routing, 4 role-based portals, 5 daily jobs and 1,024 automated tests (PropDesk case study). Beds, term options and holds are new work on those patterns, and are quoted as new work.
• Concurrency is tested, not assumed. Holds are tested by firing simultaneous bookings at a real PostgreSQL database, and asserting no bed is ever held or confirmed twice.
• Multi-operator by design. BlockEstate, a multi-tenant listing and inquiry platform, reached its MVP in 6 weeks. Keeping operators' buildings apart on one platform is the same problem. See the real estate industry page.
• Clear terms. A free 15-minute technical audit, then a fixed written quote; fixed scope or a dedicated monthly team. You own the IP, and an NDA is standard. SaaS development covers what a platform build includes, and MVP development covers a first release.

When you don't need us

• You run buildings on standard annual contracts. An established student housing platform already does this; buy it.
• You are a university that needs deep student-record integration. A vendor with existing integrations is usually the lower-risk route.
• You need a native iOS or Android app. RAITHub builds web apps and PWAs only.
• You need tenancy, licensing or data-protection advice. Ask a local adviser; RAITHub builds the rules they confirm into software.
• You need someone on site, or a certified vendor. RAITHub has no local offices and holds no SOC 2 or ISO 27001 certification.

If your booking system already double-books beds or drops payments, start with a fix before rebooking season.

Sources checked on 30 September 2026. Legal points are general information only; confirm the current rule with your adviser.

If you are planning a student accommodation platform or a booking layer for your buildings, book the free 15-minute technical audit. Bring your room types, your term options and last year's busiest booking week.

Frequently asked questions

What is a student accommodation management system?

It is software that runs student housing: bed inventory, term-based contracts, bookings, instalment payments, arrivals and departures, maintenance and rebooking. It differs from general property management software because contracts follow the academic year and most bookings arrive in a short peak.

How do you stop a student booking system double-booking a bed?

Lock the bed's row with SELECT ... FOR UPDATE inside a transaction, re-check availability, and insert a hold with an expiry. Add a database exclusion constraint that rejects overlapping live bookings on the same bed, so even a buggy code path cannot double-book.

How long should a booking hold last while a student pays?

Long enough to pay, short enough not to block others: 30 to 35 minutes is a practical start. Stripe Checkout sessions can expire from 30 minutes to 24 hours after creation, so set the session to expire before your hold does.

Should student accommodation contracts be modelled as subscriptions?

Usually not. A term contract has a fixed total and fixed dates, so model it as a total split into scheduled instalments in integer minor units. Invoice each instalment on its due date, and calculate any mid-term change yourself.

Has RAITHub built student housing software?

No. RAITHub built PropDesk, a property management platform with Stripe rent collection, leases, 4 role-based portals, 5 daily jobs and 1,024 tests. Those patterns carry over; bed inventory, term options and booking holds would be new work.

Should a PBSA operator build or buy software?

Most should buy: established platforms cover bookings, contracts and rebooking for standard annual contracts. Build when the software is your product, when your booking journey is how you compete, or when you sell the same beds on several term types that tools handle poorly.