Skip to content
       

Blog

The Future Doesn't Need More Apps

The Future Doesn't Need More Apps

It is Monday morning. A regional property manager opens the leasing system to check a move-in, switches to the accounting package to chase an arrears figure, jumps to the maintenance tool to see why a work order has stalled, opens a spreadsheet to reconcile a number that two of those systems disagree on, and answers an owner's email asking for a report that lives in none of them. It is not yet ten o'clock, and almost none of that was the work. It was the moving between the things that hold the work.

Ask that manager what would help and someone will eventually name an app. A better inspection tool. A dedicated arrears tracker. A slicker portal. The instinct is understandable and almost always wrong, and the next decade of software is going to expose why.

Here is the claim this piece defends. The future of property technology is not more apps, and it is not even one big app to replace the many. It is less software that a person has to operate at all. The problem was never the number of tools; it is how much manual work those tools quietly leave on a human being's plate. For thirty years the industry has measured progress by how many capabilities it could put in front of a user. The measure that will matter next is the opposite: how much work the software takes off the user's plate entirely. The winning tools will be judged not by what they let a property manager do, but by what they stop requiring a property manager to do.

The Human Became the Integration Layer

Look again at that Monday morning, because something has quietly happened to the person in it. Each of those systems was bought to solve a real problem, and each did. But nobody was ever assigned the job that emerged from having all of them at once: moving information between them, reconciling what one says against another, and remembering which system holds the version of the truth that matters right now.

That job exists. It is simply unassigned, which means it landed on the human by default. The person became the integration layer, the connective tissue holding a dozen disconnected tools together with copy-paste, memory, and vigilance. It is the least visible job in the operation and one of the largest, and no line in any budget accounts for it. The biggest cost of fragmented software is not the licensing; it is the attention your team spends stitching the systems together.

The scale of it is now measured. In a 2022 study published in the Harvard Business Review, researchers tracked 137 people across three Fortune 500 companies and found that workers toggled between applications and websites roughly 1,200 times a day, losing just under four hours a week simply reorienting themselves after each switch, around 9% of their time at work. That is five working weeks a year, per person, spent not doing work in any tool but crossing the gaps between them. The fragmentation compounds the toll: Asana's Anatomy of Work research found the average knowledge worker uses around ten applications a day, spending a large share of the week on coordination overhead rather than the skilled work they were hired for. For a property team stitching together leasing, finance, and maintenance across a portfolio, that toggling is not incidental. It is a large part of the actual day.

More Apps Makes the Real Problem Worse

Now watch what happens when the industry responds the way it habitually does: by adding another app.

The arrears are hard to track, so a team buys a dedicated arrears dashboard. It is genuinely better at showing arrears than the accounting system was. But it is one more place to log in, one more source that can disagree with the ledger, one more screen someone has to remember to check, and one more handoff where a number gets carried across by hand. The team is now better at seeing arrears and no better at collecting them, because collecting was never a visibility problem. It was a question of whose job it is to act, across which system, and a new app does not answer that. It adds to it.

Be fair to the app, though, because this is where the argument is easy to overstate. A specialized tool is often genuinely better at its narrow job than a generalist platform would be; the inspection app really does inspect better. The problem is not specialization itself. It is that every specialized tool arrives with a handoff attached, a new seam between it and everything else that a person has to sew shut by hand. The capability is real, and so is the tax, and the industry only ever puts the first one on the pricing page. The authors of the HBR study reached the same conclusion from their data, warning that simply adding capacity to cover for badly designed work does not fix it, and that leaders should look instead at where the design of the work itself is causing the friction.

What "Fewer Apps" Actually Means

It would be easy to read this as "consolidate onto one platform," and that is not quite the point, because a single platform that still makes a person do all the same work, just behind one login, has only tidied the problem rather than removed it.

The real shift is that software should stop being a place you go and start being a thing that happens. The unit of the old model is the destination: an app you open, a screen you read, a form you fill, a system you check. The unit of the new model is the outcome: the renewal that gets actioned, the arrears case that gets worked, the maintenance job that gets closed, arriving as work already in motion rather than a tab waiting for you to notice it.

Take the lease approaching expiry. In the destination model, that fact is true somewhere in a system, and whether anything happens depends on a person opening that system, spotting the date, and starting a process. In the outcome model, the expiry does not wait to be discovered: it generates the renewal task, routes it to the named owner, and chases it to completion, pulling a person in only when a decision genuinely needs one. The first model needs the human to be the engine. The second needs the human only for judgment. That is what "fewer apps" really means: not fewer logos on the login page, but less of the operation depending on a person remembering to go and look.

Two Models of Property Software

The Destination Model

The Outcome Model

Software is a place you go

Software is work that happens

Measured by features it offers

Measured by work it removes

The human integrates the tools

The system integrates itself

Value is what you can do in it

Value is what you no longer have to do

Success is adoption and logins

Success is outcomes completed unattended

More capability means more apps

More capability means less human operating

Why the Industry Keeps Selling You Apps

If the future is less software to operate, why is the industry still selling more of it? Because the incentives point that way. An app is easy to sell and a removed task is hard to.

An app demos well. It has a screen, features you can point at, a price, and a start date, and a buyer can evaluate "here is a tool that does X" in a single meeting. "Here is a way for X to stop needing you" is harder to package, because its value shows up as an absence: work that no longer happens, time that stops being spent, a job that quietly disappears from someone's week. Absences do not photograph well in a product tour, so the market keeps optimising for what is legible in a demo, which is capability, and keeps under-serving what actually helps, which is the removal of work. Buyers complete the loop, because the instinct when something is hard is to reach for a tool, and there is always a tool to reach for. The result is portfolios that are richer in software and poorer in attention every year.

What This Means Before You Buy the Next App

The practical shift is to change the question you ask of any new piece of software.

Ask what it removes, not what it adds. The seductive question is "what can this do?" The useful one is "what will my team stop having to do once this is in place?" If the honest answer is "nothing, but they'll be able to see more," you are buying a destination, and destinations are the thing you already have too many of.

Count the handoffs, not the features. Before adding a tool, trace how many times information will now have to move by hand between it and everything else, who will carry it, and what breaks when they are on leave. Each new app is a promise of a feature and a hidden tax of handoffs. The feature is on the pricing page. The tax is on your team.

Judge software by the work that disappears. The measure that predicts whether a purchase actually helps is not logins or engagement, which reward software for consuming more of your team's attention. It is how many things now happen without anyone opening anything. The best outcome from good software is not a team that spends more time in it. It is a team that barely has to touch it, because the work it governs is getting done.

So return to that Monday morning. If a property manager still begins every week by opening six systems and stitching them together by hand, the software has not reduced the work. It has only reorganised it, and handed the hardest, most invisible part back to a person. That is the real test, and it is the one the industry has been avoiding. More apps was always the wrong goal, because the app was never the point; the outcome was, and the app was just the toll you paid to reach it. The next generation of tools will be judged not by what they let a property manager do, but by how little they need one to do at all, and they will win by asking less of the people who use them, not more.

Frequently Asked Questions

1. Does property management really need fewer apps?
The point is less about the raw number of apps and more about how much work the software requires a person to do. Multiple tools become a problem when the human is left to integrate them by hand, moving data between systems and remembering which holds the current truth. The goal is software that removes that connective work, whether that means fewer tools or better-connected ones.

2. What is the "toggle tax"?
It is the time and focus lost to constantly switching between applications. A 2022 Harvard Business Review study found workers toggle between apps around 1,200 times a day and lose nearly four hours a week just reorienting after each switch, roughly five working weeks a year. For property teams working across leasing, finance, and maintenance systems, that overhead is a significant and largely invisible part of the day.

3. Why does adding a new app often make things worse?
Because each new tool solves one narrow problem while adding to the larger one: more logins, more sources that can disagree, more screens to check, and more handoffs where data is carried across by hand. A specialized app can be excellent at its own job and still increase the overall fragmentation that was the real problem.

4. Isn't the answer just to consolidate onto one platform?
Consolidation helps, but only if it actually removes work. A single platform that still makes a person perform all the same steps behind one login has tidied the problem rather than solved it. The deeper shift is toward software that acts on outcomes, routing and completing work, rather than simply presenting more screens for a person to operate.

5. What does it mean for software to deliver outcomes instead of being a destination?
A destination is something you open and operate: a screen to read, a form to fill, a system to check. An outcome-based tool acts on its own, for example detecting a lease expiry, creating the renewal task, routing it to an owner, and chasing it to completion, and only involves a person when genuine judgment is needed. The human is used for decisions, not for moving work between systems.

6. How should a property company evaluate its next software purchase?
By what it takes off the team's plate, not what it lets them do. Ask what work will stop being necessary once it is in place, count how many manual handoffs it adds between systems, and judge it by how much gets done without anyone opening it. Software that only adds capability without removing effort tends to increase the operating burden rather than reduce it.