Cloud-Native Rebuild That Tripled Feature Velocity for Proptech

The Company

Fairbrick Living is a proptech company that builds the operating layer for residential property management: tenant and owner portals, rent collection, leasing workflows and maintenance dispatch. The platform serves property managers overseeing 12,000 rental units, and its product sits in the unglamorous but mission-critical middle of the rental economy — when a water heater fails or a rent run processes on the first of the month, property managers expect Fairbrick's software to simply work. The company employs a mid-sized product and engineering organization that ships continuously to tenants, owners and property managers through web and mobile interfaces.

That market context matters for one specific reason: speed is the product. Property managers choose between Fairbrick and competitors on how quickly new workflows arrive — new payment options, new inspection checklists, new owner reporting — because those features are what they resell to their own boards and owners. McKinsey research reports that companies in the top quartile of developer velocity achieve revenue growth up to five times faster than bottom-quartile peers, and Fairbrick's leadership had read that research with growing discomfort, because their own feature velocity had been slowing for years while their roadmap backlog grew.

Where Things Stood

Fairbrick's entire platform ran on a 10-year-old PHP monolith with a jQuery front end, nightly cron jobs and hosting on a single aging VPS. The system had accreted a decade of features into a codebase where modules reached into each other's database tables, and nobody could change one workflow without tracing side effects through three others. Feature lead times stretched past three months, and roughly 60% of engineering capacity went to untangling side effects rather than building new capabilities. There was no automated test suite, so manual QA caught what it could — and the rest surfaced in production, often at the worst possible moments.

Some failures were so regular they had become part of the company's folklore. Rent-collection days — the first of every month, when payment volume spikes — brought predictable outages, and the operations team planned around them the way farmers plan around weather. Mobile users abandoned application flows at twice the desktop rate because the jQuery front end had never been designed for small screens or weak connections. The situation turned acute when a security disclosure on the unsupported framework version forced an emergency patch weekend, consuming the entire engineering team's attention while feature work stopped. Around the same time, two enterprise property-management prospects lost RFP competitions and cited the platform's sluggishness in their feedback, and recruiting had become its own crisis: engineers who interviewed with the team asked pointed questions about the stack and accepted offers elsewhere.

The Challenge

The challenge was a platform whose cost of ownership had quietly become the company's largest strategic liability. Stripe's Developer Coefficient survey reportedly found developers spending a third or more of their time on technical debt and maintenance rather than new features — Fairbrick's engineers were spending closer to 60%, which meant the company was paying full engineering salaries for what was, in effect, archaeology. DORA research consistently links stronger software delivery performance to better overall organizational outcomes including profitability and market share, and Fairbrick sat at the wrong end of that correlation: deployments were rare, risky events that everyone feared.

The rewrite question carried well-known dangers, and the team was honest about them. A big-bang rewrite would freeze feature work for quarters while competitors shipped, and industry folklore is full of rewrites that never finished. Continuing on the monolith was equally untenable: the security disclosure proved the framework was a liability, the lost RFPs proved customers noticed, and the recruiting problem proved the talent market had voted. The real challenge was therefore a third path — rebuilding the platform module by module while a live business kept running on the old one, with the property managers' rent runs, maintenance tickets and leasing pipelines never interrupted. It also required an organizational commitment: parallel platforms mean doubled operational attention, and someone had to decide, on a schedule, when the old system dies.

Discovery and Diagnosis

Emerson Technology began with a focused discovery phase that treated the monolith as evidence rather than as an enemy. The team instrumented the legacy system to observe real traffic, then used version-control history to identify which modules changed most frequently, which modules failed most often in production, and where the two overlapped. That analysis cut through a year of abstract architecture debate: payments, leasing workflows and maintenance dispatch were simultaneously the highest-change, highest-failure, highest-revenue modules, which made them the obvious first targets for rebuild. Modules that had barely shipped in years — certain reporting screens, legacy admin tools — were explicitly deferred, because rebuilding them early would spend scarce attention on code that rarely mattered.

The second diagnostic thread was behavioral pinning. Before any rewrite, the team wrote contract and characterization tests around the legacy seams that the first new services would touch, capturing what the old system actually did — including its edge cases and its bugs — so the new implementations could be compared honestly against observed behavior rather than against documentation that had drifted from reality. The discovery phase also surfaced the operational constraints that any solution had to respect: rent-collection runs could not move until their replacement had survived several cycles of shadow traffic, and the single VPS meant there was no staging environment, so preview infrastructure had to be part of the new platform's foundation rather than an afterthought. The output was a sequenced migration plan with business value, not architectural elegance, as the ordering principle.

The Solution

The rebuild followed a module-by-module strangler migration rather than a big-bang rewrite: the monolith kept running every workflow it owned until its replacement had proven itself against live traffic, and the legacy PHP codebase was switched off nine months after kickoff. The new platform was deliberately conventional, because the goal was velocity and hire-ability, not novelty.

The new stack

The tenant and owner portal is a Next.js application backed by Node.js services running on AWS ECS, with PostgreSQL on Amazon RDS as the system of record. Redis-backed queues absorb the sharp, predictable bursts — payment runs on collection days and notification storms when maintenance statuses change — so a spike in one workflow no longer starves every other. Shared business logic moved into typed service modules with contract tests at their boundaries, which is what lets teams change a payments rule without re-reading the leasing codebase. The stack was chosen for boringness on purpose: Next.js, Node and Postgres are technologies the local hiring market knows deeply, which addressed the recruiting failure directly.

The path to production

Terraform and GitHub Actions gave every feature branch its own preview environment and an automated path to production, ending the practice of QA-ing on a shared server that everyone's changes contaminated. Structured logging and Sentry tracing made failures diagnosable in minutes rather than archaeology sessions, and DORA metrics — lead time, deployment frequency, change failure rate — were published internally so improvement was measured rather than asserted. This delivery machinery mattered as much as the application code: a rebuild that lands on the same manual deployment habits simply reproduces the old pain with newer frameworks.

Shadow-traffic validation

Each migrated module was validated against shadow traffic from the monolith before cutover: real production requests were mirrored to the new service, and its responses were compared to the legacy behavior the contract tests had pinned down. Payments, leasing workflows and maintenance dispatch — the modules where velocity mattered most — went first under this discipline. Shadow comparison caught integration gaps that even careful test plans consistently miss: a tax-calculation rounding difference in billing, an edge case in how legacy code had handled prorated leases. Each was fixed before customers ever saw the new path, and each would have been a support emergency under a big-bang cutover.

The First 90 Days

The first month was spent almost entirely on foundations and pinning. Contract tests were written around the payments and leasing seams, the Terraform baseline for ECS, RDS and networking was reviewed and merged, and the preview-environment pipeline was stood up so that every subsequent line of code shipped through the new machinery. A named triage owner took responsibility for all legacy fixes during this period — a deliberately unglamorous role that shielded the rebuild team from the constant feature firefights that quietly double every migration timeline it touches. The team also announced, in week three, a sunset date for the legacy stack and began tracking monolith usage on a visible burn-down chart, converting an open-ended migration into a project with a deadline.

Weeks five through eight delivered the first production service: the payments module, running behind a feature flag while shadow traffic validated it against the monolith. In week nine the first cutover happened, and rent-collection day the following Monday was the real exam — it passed without an outage, the first clean collection day in memory. Weeks ten through twelve extended the pattern to leasing workflows, with weekly cutovers replacing the monthly ritual, and lead-time metrics published where the whole company could see them. By day 90, three of the five priority modules were live on the new platform, the deployment frequency graph had already inflected upward, and — the metric the leadership team watched most closely — the two enterprise prospects that had walked away accepted renewed demonstrations.

The Results

Feature velocity tripled. The team now ships more than 30 production changes a month against single digits before, and lead time from idea to production fell from three months to under two weeks. Portal page loads dropped 70% because the Next.js front end replaced a jQuery application never designed for performance, and mobile application completion rose 35% as the flow finally worked on the devices tenants actually use. Rent-collection days have run clean for a full year — the predictable outages are now stories new employees hear rather than nights they live. The two lost RFP accounts returned as customers within two quarters, and engineering attrition dropped to zero once the legacy stack, and the 2 a.m. cron alarms, were retired.

The less quantifiable changes compound the headline numbers. Product managers stopped batching features into large, risky releases because shipping small became cheaper than shipping big. Engineers began trusting the codebase — the word that appeared in the follow-up hiring interviews — because contract tests and preview environments made changes reversible and visible. And the roadmap conversation changed character entirely: once velocity tripled, the constraint on strategy stopped being what the platform could absorb and became what the market wanted next, which is the position a product company wants to be in.

What Your Business Should Do

If your platform is aging but your business is live, the Fairbrick sequence transfers almost directly. Migrate by module, not by big bang: rebuild the highest-value workflows first and route shadow traffic through them before cutover, because parallel-run validation catches integration gaps that even careful test plans consistently miss. Add tests to the legacy seams before you rewrite anything — contract and characterization tests pin down what the old system actually does and prevent the expensive surprises that sink rewrites. Choose boring, mainstream technology that your local hiring market knows deeply; exotic choices compound recruiting pain for years after launch day. Then build the golden path to production — automated build, test and deploy so every merge can ship safely — because a one-command path is what removes the friction that pushes teams toward batching risky changes.

Run the migration as a business program, not a science project. Sequence the work by revenue impact and change frequency rather than by architectural elegance, and let the velocity gains from early modules fund patience and goodwill for the rest. Set a deadline for the legacy stack, announce it internally, and track usage on a visible burn-down chart — open-ended migrations drift for years, while real dates force decommission decisions. Measure velocity publicly: publish lead time, deployment frequency and change failure rate where the whole company can see them, which both sustains momentum and attracts exactly the engineers you need. Finally, protect the first 90 days of focus by naming a clear triage owner for legacy fixes; constant context switching quietly doubles every migration timeline it touches. While you plan, hold your own team to the questions this engagement raised: what fraction of your sprints maintains systems nobody would choose today, which two modules would unlock the most customer-visible velocity if rebuilt first, how long you could tolerate two platforms in parallel and who decides, and which deals you have lost to a faster competitor this year. Work through these eight steps with your team using the action checklist in this practice book, and revisit the reflection questions each quarter so the rebuild keeps serving the business instead of becoming a monument.