Client overview
Two River Development builds, renovates, and manages affordable housing in Philadelphia. Voucher-approved units, PHA and Section 8 tenancies, general contracting, and full-service property management across a portfolio that runs into the hundreds of units. It is a real operating company — buildings, tenants, and a leasing team that answers the phone.
Rekreate's engagement covers two halves of the same system: the operational intelligence platform that runs the company's back office, and tworiverdevelopment.com, the public website that sits on top of it. We designed, built, deployed, and continue to operate both, working closely with Two River's leadership throughout.
One thing worth saying plainly, because it's the part no agency can claim: the business is theirs. The properties, the acquisitions, the renovations, the housing-authority relationships, the tenants, the team. We built the systems the company runs on. They built the company.
The challenge
Two River had the problem that every growing rental operation eventually has, and it isn't a design problem.
The business ran on a stack of separate systems — leasing, accounting, banking, phones, CRM, city compliance data. Stacks like that develop a familiar symptom: the systems stop agreeing about basic facts. How many properties do we have? How many units? Which entity owns which building? Questions like those end up with two or three answers depending on which system you ask, and a straight answer means somebody reconciling spreadsheets by hand. The reconciliation figures below say how much of that had accumulated here.
A hand-maintained public website inherits that problem in its most visible form. Vacancy information lives in the leasing platform, where it belongs; the website keeps a separate copy. The two agree on launch day and drift apart immediately — a unit leases on Thursday and sits on the site for three weeks, rents change in one place and not the other, four units come online during a maintenance emergency and nobody remembers to post them.
When that happens, the leasing team learns to stop trusting its own website and goes back to telling callers "let me check and get back to you" — and a site the team has to double-check by phone is generating work instead of removing it.
Meanwhile the inbox had become its own operation. Tens of thousands of unread messages, real ones buried among automated notifications, and no reliable way to tell which was which.
So the brief had two halves, and the order mattered:
- Underneath: one source of truth for the business, and automation on top of it, so the company's own data could be trusted.
- On top: a fast, credible website whose vacancy pages tell the truth without anyone maintaining them, that lets a prospect book a tour at midnight, and that a housing caseworker or a prospective owner can take seriously.
You cannot build the second one honestly without the first. That's the through-line of this entire project.
Part one — the operations platform
The platform went from first line of code to running the business in roughly 15 weeks, across thousands of commits. It runs on ~$25/month of infrastructure, doing work that would cost $50,000+ a year assembled out of equivalent SaaS subscriptions.
Here's what it does.
1. One source of truth
The foundation is a reconciliation engine that resolves the company's core facts into a single authoritative record: 150+ properties, 400+ units, and over two dozen legal entities, tied together and checked against each other.
Before this, "how many units do we have" was a research project. Now it's a lookup — and every other system, including the public website, reads from that answer instead of keeping a private copy. When the underlying data drifts, the engine fails loudly rather than quietly serving a plausible wrong number.
This is the least glamorous part of the build and the reason everything else works.
2. Email operations
The company inbox had accumulated a backlog that no person was ever going to clear by hand. We cleared more than 50,000 messages out of it, then built the rules engine that keeps it clear: 1,000+ routing rules that file, prioritize, and escalate what arrives, plus scheduled digests that surface what actually needs a human.
The effect for the team is that the inbox went from a place where things get lost to a queue that can be worked.
3. Leasing pipeline, end to end
An inquiry now moves through the system without anyone shepherding it: it lands, syncs into the CRM automatically, and propagates to the team's contacts so the phone shows a name instead of a number when that person calls back. Showings get scheduled, auto-populated, nudged for follow-up, and swept at end of day so nothing falls through. Daily audits post what's stalled.
The leasing team's job became working prospects instead of doing data entry between prospects.
4. Phone and voice
We pulled and analyzed the company's full call history — a corpus of more than 100,000 calls — classified all of it, and mined it into a leasing knowledge base built from how the team's best conversations actually go, rather than from a script somebody imagined. Missed calls now trigger an automatic text back within a minute, so an unanswered ring stops being a lost lead.
5. Accounting and banking
The accounting system, the property management platform, and the bank feeds are pulled into one reporting layer, reconciled against each other, with exceptions surfaced to the team automatically instead of discovered at month end. Bank-versus-book reconciliation runs against a real trust model rather than a spreadsheet convention.
6. Philadelphia compliance
Affordable housing in Philadelphia carries a compliance surface most software ignores entirely. The platform reads the city's own data — rental licensing, fire and sprinkler certification, property records — and reconciles it against the company's records, so a lapsed certificate surfaces as an alert rather than as a violation notice.
This is the kind of thing off-the-shelf property software will never do for you, because it's specific to one city and one business.
7. The autonomous layer
Underneath all of it: 40+ scheduled jobs running unattended, a 75+ endpoint internal API serving every consuming surface, nearly 200 routing rules governing agentic behavior, and a conversational assistant, reachable in the team's chat tool, that can answer questions across every connected system without anyone opening five tabs.
The design rule we held throughout: an action that is destructive, outbound, or irreversible always stops for a human. Everything reversible runs on its own.
8. The operations dashboard
A React dashboard gives the team the views they work from — leasing pipeline, phone traffic, work items, accounting, compliance status — reading from the same source of truth as everything else, with per-user authentication and scoped access so each operator sees their own lane.
Part two — the public website
1. The site — tworiverdevelopment.com
A React and TypeScript build, statically pre-rendered — every route ships as finished HTML rather than an empty shell that fills in after JavaScript runs. That decision matters more in real estate than in most categories: search engines, ad platforms, and link previews all read the HTML, and a listings page that only exists after a fetch is a listings page that, to a crawler, contains no listings at all.
The site covers what the business needs to say: available housing, the rental portfolio, PHA and voucher services for tenants and separately for owners, general contracting, consulting and development, the team, testimonials, FAQs, and a resource library for renters, owners, and caseworkers. It builds out to about 120 pages — of which around twenty were written as pages. The rest generate themselves from data: one per available unit, one per property in the public rental portfolio.
2. Vacancy pages that rebuild themselves
This is where the two halves meet, and it's worth being precise about the mechanism.
The operations platform holds the live vacancy data. Before every build of the website, a step pulls the current listings from it. Each vacant unit becomes its own page — its own address, rent, bed and bath count, neighborhood, photos, description, page title, meta description, canonical URL, and RealEstateListing structured data so search engines read it as a property rather than as text.
Then the whole site rebuilds and deploys on a schedule, every morning, before the Philadelphia business day starts. No code change required. Nobody on the leasing team touches the website. A unit leases and its page comes off; four units come online and four pages appear.
Two safeguards in that pipeline are the difference between an automated system and an automated liability:
- An unreachable feed never breaks a deploy. The build ships with the last known-good listings, and the browser still checks the live feed on every visit — a unit that leased overnight corrects itself in front of the visitor.
- An empty feed can't wipe the page. Zero listings is far more likely to be a maintenance window than a genuinely vacancy-free portfolio, so the build refuses to replace a non-empty list with nothing.
3. Tour booking and application flows
Every unit page carries a scheduling flow, so a prospect can book a tour at 11pm without reaching a voicemail — and tour-intent traffic can be sent directly to a specific unit with its booking step already open, rather than dropped on a generic homepage to find its own way.
The application path is handled on the site rather than bouncing prospects straight into a long third-party form, and the site carries campaign and visitor context through to submission, so the company can tell which listings and which channels actually produce applicants — not just which ones produce traffic.
(A conversational apply flow is in development. It is not live, it's pending legal review for fair-housing compliance, and we're not going to present it as shipped.)
4. A deploy pipeline that fails safely
Merging to the main branch deploys the site. That sentence is easy to write and is where most small-company websites quietly rot, so here's what happens:
The build runs, the new release is copied to the server, and the live site switches to it in a single atomic step. Then the deploy checks the live public URL — through the CDN, exactly as a visitor would reach it — and requires the response to contain that specific build's fingerprint, proving the new release answered rather than a cached copy of the old one. If the check fails for any reason, the previous release is restored automatically and the team is alerted. The public site keeps serving the last good version throughout.
A bad deploy is a red notification, not a down website. For a company whose site is a leasing channel, that distinction is the whole ballgame.
5. Technical SEO built into the pipeline
The sitemap is generated from the actual build output after every build, so it can't drift from what's really deployed — the failure mode of every hand-maintained sitemap, including the one it replaced. Structured data covers the page types that earn it: property listings, services, team members, testimonials, FAQs, and article breadcrumbs. Unknown URLs return real 404s instead of a soft 200 that quietly poisons the index, and legacy URLs from the previous website redirect properly instead of dead-ending.
How the two halves work together
Most agencies would build Two River a website and stop. It would look good, and it would be wrong by March.
This one stays current because it isn't the source of anything. It's a rendering of a system the company already has to keep accurate for its own operations — because leasing, accounting, and compliance all depend on the same records. The website inherits that accuracy for free.
That inversion is the differentiator, and it's why we now build websites and operations platforms as one engagement rather than two:
- The operations platform is where facts live, because that's where the business already keeps them.
- The website is one of several surfaces reading those facts. The dashboard is another. The team's daily reports are another.
- Nobody maintains a second copy of the truth, so there's no second copy to go stale.
A template website can't do this — not because template tools are bad, but because there's nothing on the other end to read from. The integration was never the hard part. Having something worth integrating with is.
The outcome
The operations platform:
- ~15 weeks from first line of code to a platform running the business, across thousands of commits
- ~$25/month in infrastructure, doing work that would cost $50,000+/year assembled from equivalent SaaS subscriptions
- 150+ properties, 400+ units, and over two dozen entities reconciled to a single source of truth
- 50,000+ backlog emails cleared, with 1,000+ routing rules now handling what arrives
- 100,000+ calls analyzed into a leasing knowledge base
- 40+ autonomous scheduled jobs, a 75+ endpoint internal API, and nearly 200 agentic routing rules in production
- Thousands of dollars a year in directly cancelled software subscriptions, before counting the SaaS the platform made unnecessary
The public website:
- tworiverdevelopment.com — statically pre-rendered, roughly 120 pages
- Vacancy pages that rebuild themselves every morning from the operations platform, each unit carrying its own metadata and property structured data
- Tour booking and application flows on every unit, with campaign attribution carried through to submission
- A deploy pipeline that verifies the live public site and rolls itself back if the new release doesn't answer correctly
- Technical SEO wired into the build — self-generating sitemap, structured data, real 404s, legacy redirects
Built once, owned by the client, running on infrastructure they control.
What this means for other property owners and operators
If you own or manage rental property and your website's vacancy list is wrong right now — go check, it takes thirty seconds — the fix isn't a redesign. A prettier version of a hand-maintained list goes stale on exactly the same schedule.
The fix is that the website stops keeping its own copy. Whatever system your team already lives in should feed it, so the page is correct as a side effect of your team doing their normal job rather than as a task they'll skip during a busy week.
And if the honest answer is that no system you own is accurate enough to feed a website — that "how many units do we have" has three answers depending on who you ask — then the website was never the real project. That's the more common situation, and it's a better problem to find out about now.
We wrote up the general version of this — what a rental website should actually do, what it costs, and how to tell if yours is losing you money — in Do You Need a Website for Your Rental Property Business?
If you run a real estate or property management business and you want the version where the operations and the website are built as one system, that's the work we do: agentic operations platforms and real estate web development for property management companies. Let's talk.
Common questions from property owners
Can you integrate with the leasing platform we already use?
Usually, though the route differs from platform to platform — a feed, an API, or an intermediate system that already talks to yours. Worth establishing before anyone quotes you a price, because the answer changes the build. The principle doesn't change: one source of truth, and every surface reads from it.
Do I need the full operations platform to get the live-listings website?
No. The website integration is its own project, and if your leasing platform exposes usable data we can wire directly to it. The platform work becomes worth it when the problem is bigger than the website — when several systems disagree about basic facts and reporting means reconciling spreadsheets by hand.
How long does a build like this take?
The website portion, including listings integration, per-unit pages, tour booking, and the deploy pipeline, runs roughly eight to fourteen weeks depending on how much content exists and how cooperative your leasing platform is. A full operations platform is measured in months — Two River's core build ran about fifteen weeks and has kept growing since.
What happens if my listing data source goes down?
As built here: the last known-good listings stay up while the system retries — never an error page, never an empty vacancy list. It's also a question worth putting to anyone quoting you a listings integration.
Is an AI system safe to run against real tenants and real money?
Only with the gates built in from the start. On this platform, anything destructive, outbound, or irreversible — sending, spending, deploying, deleting — stops for human approval by design. Automation handles what's reversible. That boundary is built into how the system is structured, not a setting someone can flip.
Who owns the platform and the code?
The client. Domain, repositories, hosting, deployment pipeline, and data. We build it, you own it, and we run it for as long as you want us to.
Do you work with US clients from the Philippines?
Yes. Two River is a Philadelphia company and we're based in Manila. The deploy pipeline doesn't care what time zone triggered it. If you want a number for your own situation, get a scoped quote on a call — it takes about thirty minutes.
