Finding the problem
Student housing search is full of mismatched tools. Listings are scattered, the information students need is inconsistent, and the path from discovery to a safe conversation is often improvised. RentSwipe began with a simple interaction idea - make discovery fast and legible - but the real product problem was trust.
As co-founder and technical lead, I translated that problem into a product surface and an operating system: student and landlord roles, listings, preference-aware discovery, applications, messaging, moderation, and the workflows needed to support them.
The product shape
The iOS client is written in Swift and SwiftUI. State-driven views keep loading, success, empty, and failure paths explicit. Navigation and interaction patterns use native platform conventions so the distinctive swipeable discovery mechanic does not make the rest of the product unfamiliar.
The backend runs on Cloudflare Workers, with D1 providing relational persistence for users, listings, applications, conversations, and moderation records. Indexed access paths were designed around the screens and jobs the application actually performs rather than added after slow queries appeared.
Trust as architecture
Messaging is not a generic table with a text field. Blocking must change what both parties can see and do. Reports need durable context. Rate limits must distinguish normal conversation from abuse. Content rules need enforcement points on the server, not only a warning in the interface.
Those requirements shaped schemas, authorization checks, and audit records from the beginning. Role-based access is verified at the resource boundary. Client state can improve the experience, but it is never treated as proof of permission.
Engineering the venture
Startup work continuously changes the order of implementation. A promising screen can become irrelevant after a user conversation; an operational concern can suddenly outrank a polished interaction. The engineering approach is to keep boundaries clear enough that learning changes priorities without turning every change into a rewrite.
That means small vertical slices, observable APIs, migrations that can move forward safely, and product decisions recorded beside technical consequences. “Whole stack” here includes choosing what not to build and making the unfinished parts honest.
Field notes
RentSwipe is where product judgment and engineering judgment meet. The interesting question is rarely whether a feature can be implemented. It is whether the feature creates enough value, whether it can be operated responsibly, and whether its architecture leaves room for what the next conversation teaches.
Finding the problem is half the job. Staying close enough to notice it changed is the other half.