How We Rebuilt a Fragmented Platform Into the Operating System for 685,000 Customers

Spruce's Legacy Platform Modernization

The Objective

Spruce had become something most startups aspire to: a large, multi-sided service platform with hundreds of thousands of customers across multiple US markets. The problem wasn’t the business. The problem was that the technology underneath it had never been built for the business it became. We fixed that. Properly, completely, across every role and every workflow.

Tech Stack

React JS React Native Node.js PostgreSQL Firebase AWS Braintree Braze Mixpanel Slack

The Impact

685K+
Customers on platform
A user base that the old architecture could not have supported reliably
6,477
Properties managed
Every one running through a single, unified system for the first time
7,581
Property management companies
Operational visibility they previously had to chase manually
67
Service providers
Now fully on-platform — no external coordination required
The Client

A Platform at the Edge of What Its Technology Could Hold

Spruce is a US-based property services platform connecting residents, property managers, and vetted service professionals for on-demand and recurring home services. By the time they found AppVerticals on Upwork, they were already operating at real scale — hundreds of thousands of customers, multiple US markets, a multi-sided business that touched nearly every part of the residential services ecosystem.

They weren’t looking for a vendor to add features. They were looking for someone who could look at what they’d built, tell them the truth about it, and fix it properly. That’s the conversation we had, and it’s the one that led to the rebuild.

The Problem

Incremental Decisions Had Become a Structural Problem

There’s a pattern we recognise immediately in platforms that have grown the way Spruce did. The technology gets built in phases — each one solving the problem in front of the team at the time, with little room to anticipate what comes next. That’s not a failure of judgment. It’s just how early-stage companies survive. But at a certain point, the accumulated decisions stop enabling growth and start resisting it. Spruce had reached that point.

Service professionals had no mobile app. They were managing jobs through a combination of the web portal, messages, and phone calls — a fragile operational chain for a business whose entire model depends on the right person arriving at the right place at the right time with the right information.

Property managers had a portal that showed them bookings existed but couldn’t show them what they needed to actually manage their portfolios. Anything meaningful required going outside the system. Admins had no real-time view of service provider capacity, which meant overbooking wasn’t a risk — it was a regular occurrence, caught manually by whoever noticed first.

And pricing had become a patchwork. Static rates with no logic for market, unit size, or floor plan. As Spruce expanded, the inconsistencies compounded. The same service was being priced differently across different contexts, and there was no clean fix short of rebuilding the pricing layer entirely.

None of these were isolated problems. They were symptoms of the same underlying issue: a platform that had been built for an earlier version of the business and never caught up.

Our Approach

We Decided What to Build By Understanding How People Work

The first thing we did was set aside the existing system’s structure as an organising principle. Systems that have grown incrementally tend to reflect their own history more than they reflect the people using them. We weren’t interested in inheriting that logic.

Instead, we structured the rebuild around the five roles that actually use the platform — and worked through each one with the Spruce team to understand what they needed to do their jobs, what they couldn’t do with the existing tools, and what a properly built system would make possible.

That role-by-role discipline shaped every decision that followed: what to build, how to sequence it, where complexity was worth taking on and where it wasn’t.

Service Pro Mobile App

We built a dedicated mobile app covering task management, availability, and on-site job updates — everything a service pro needs to manage their workday, in one place, on the device they're actually carrying. The coordination that used to happen outside the platform now happens inside it.

Capacity Management

We built a module that tracks service provider availability in real time and uses it to distribute incoming bookings against what's actually possible. Overbooking is no longer something the ops team catches after the fact. It's something the system prevents.

Pricing Configurator

We built pricing logic that accounts for market, square footage, and floor plan — and generates rates automatically. As Spruce enters new markets, the pricing model travels with them. It doesn't need to be reconfigured each time because the logic is built to generalise.

Property Manager Portal

We rebuilt the portal around the data managers were going outside the system to find. Property-level detail, booking history, service performance — it's all there now, in the right place, in the right form. The portal became a decision-making tool instead of a starting point before going elsewhere.

Admin Dashboard

We rebuilt the admin view around the operational questions the team actually needs to answer day to day. It works as a live management tool now, not a reporting screen you check after something's already gone wrong.

What We Built

13 Core Modules Across 5 User Roles

The scope covered every part of the platform. Each module was built for a specific role and a specific job.

Authentication & Role-Based Access
Dashboard & Reporting
Company & User Management
Properties Module
Customers & Residents
Scheduler
Bookings Management
Service Lines & Add-ons
Pricing Configuration
Capacity Management
Markets Module
Coupon & Gift Card Management
Properties Prospecting
How It Was Built

Parallel Workstreams, One Shared Direction

We made a deliberate decision early on: role-based access controls would be scoped and built before any individual module went into development. Not retrofitted afterward. This meant every part of the platform launched with permissions and data visibility already correct for each user type — a decision that added structure up front and removed an entire category of problems later.

The Service Pro mobile app and the web portal work ran in parallel. We used React Native for the mobile app — a choice that let us build and maintain iOS and Android from a single codebase, keeping the timeline realistic without trading off on platform parity.

Throughout the build, we kept the Spruce product and ops team in the room. A rebuild at this scope touches too many parts of a business to work any other way. Decisions made without the people closest to the operations tend to be technically correct and operationally wrong. We weren’t interested in that outcome.

Outcome

One Platform. Every Role. Ready for What Comes Next.

The rebuilt platform went live supporting 685,000 customers, 6,477 properties, and 7,581 property management companies. Every role in the Spruce ecosystem — residents, property managers, service professionals, and the operations team managing all of it — is now working from a single system, with the data and tools each role actually needs.

67 vetted service professionals are operating entirely through the platform. Scheduling, job management, on-site updates — all of it in one place, for the first time.

The operational gaps that had accumulated across years of incremental building are gone. But more importantly, the architecture that replaced them was designed with Spruce’s next stage already in mind. Expanding into new markets, adding new service lines, supporting a larger professional network — none of that requires starting the infrastructure conversation again from scratch. That’s what a properly built platform makes possible.

Running a marketplace or service platform that's outgrown its architecture?

We've seen this before. We know how to fix it.

Start the conversation