Every two or three years, a clever associate director, an enterprising student government, or a dean with a budget line will float the same idea: "What if we just built our own off-campus housing platform in-house?" Sometimes it is the right call. Usually it isn't. Here is a framework for telling the difference.
What "build" actually means
"Build" is rarely cheap or short. A real off-campus housing marketplace needs at minimum:
- Authentication (ideally SSO with your IdP)
- Landlord intake with file upload, ID verification, and approval workflow
- Listing management with photos, maps, search, filters
- Student-side browse, save, contact, and messaging
- Admin dashboard for your team
- Reporting and exports
- Email/SMS notifications
- Mobile-responsive web and ideally a mobile app
- Hosting, security, FERPA-aware data handling, ongoing patching
A realistic in-house build at a mid-size university — using your CS department's resources or a contractor — is 9 to 14 months for v1 and a recurring 0.5 to 1.0 FTE of engineering time for maintenance. That is before you have features like .edu verification beyond email-domain check, market analytics, or a roommate matcher.
What "buy" actually means
"Buy" usually means a white-label SaaS that ships with all of the above in week one. Your office configures branding, sets approval criteria, and goes live in 4–6 weeks. Cost is a fixed annual subscription, often in the $15K–$45K range depending on enrollment.
The tradeoff: you don't control the roadmap. If you want a feature, you either wait or pay for custom work.
When build is the right call
Build is defensible if all of these are true:
- You have committed engineering capacity — a real product manager and at least 2 full-time engineers, not a "we'll get a grad student" plan.
- You have unusual integration requirements with your SIS, housing assignment system, or financial system that no vendor will accommodate.
- Your institutional risk posture rules out third-party data processors (very rare in 2026, but real for some federally-affiliated institutions).
- You are willing to own this software for 10+ years, including the rewrites it will need.
When buy is the right call
Buy is the right call if any of these are true:
- Your housing office runs lean and "build a software platform" is not on anyone's job description.
- You need to be live this academic year, not the year after next.
- You want the vendor to handle FERPA, security, uptime, and accessibility compliance instead of your team.
- You want a roadmap shaped by every other housing office's experience, not just yours.
- You'd rather spend the budget on relationships with landlords and students, not on engineering.
The hybrid that almost no one considers
There is a third option, and it is what most modern housing offices actually want: white-label SaaS with a thin layer of office-specific customization. You get the vendor's full platform, branded as yours, with the option to add your own intake questions, your own approval criteria, your own landlord agreements. You don't write the auth system. You don't maintain the database. But the experience your students see is unmistakably yours.
If a vendor won't let you brand it or customize the intake, they aren't actually selling you "white-label" — they're selling you their brand with your logo on top. That is not the same thing.
The honest cost comparison
Most universities that build come out of the exercise wishing they hadn't. The maintenance cost is the part that always surprises people. Software is never done — it needs security patches, browser compatibility updates, accessibility fixes, new features as students' expectations evolve. Buying a SaaS amortizes those costs across hundreds of customers; building means you pay all of them yourself, forever.
If your office's time is worth more on landlord relationships, student outreach, and policy work than on writing CRUD endpoints — and it almost always is — buy.