Replacing a property portfolio's spreadsheets with a system took under four weeks to get live, and it has not stopped changing since. The repository for this one starts on 6 June 2026. The working system went live on 1 July. Five database changes shipped with the launch itself; fourteen more have landed in the five weeks since, including one feature we built and then deliberately removed. A build is not the end of the job.
This is a first-hand account of a system we designed, built and still run for a UK commercial-property firm. It is not a survey and not a vendor comparison. The firm is not named and its portfolio figures are not published here — those are theirs, not ours. What follows is everything about the work itself that is ours to tell.
What they had before
A stack of spreadsheets, which is what almost every property portfolio runs on until it cannot. Spreadsheets are genuinely good at this until three things happen at once: more than one person needs to edit, the dates start mattering financially, and the same company appears in the file twice.
That third one is not a small detail. When we imported the existing records we had to build a merge tool, because the same company had ended up in the data more than once — imported twice, or typed in slightly differently the second time. Any honest account of moving off spreadsheets includes this: the data you are moving is messier than you think, and cleaning it is part of the job rather than a step you skip.
What replaced them
A private, multi-tenant database with role-based sign-in, holding the firm's occupiers, leases, financials, properties, documents and contact notes in one place, with reporting on top. We host it and maintain it, so nobody in-house has to.
The specifically commercial parts are what off-the-shelf landlord software tends not to cover. Residential tools are built around tenancies and rent collection. A commercial portfolio needs lease events — expiries, break clauses, rent reviews — and it needs them visible before the notice period runs out rather than after. We have written separately about the key dates that cost money when they slip.
The timeline, as it actually happened
Empty repository on 6 June 2026. Live and in daily use on 1 July — twenty-five days. That is faster than the usual quoted range for a bespoke build, and the reason is narrow scope: we built the thing the firm actually needed rather than the thing that would demo well.
Five changes to the database shipped as part of go-live. Fourteen more have landed since, the most recent on the morning this was written. That is the honest shape of a working system: it is not delivered and finished, it is delivered and then kept.
The part we built and then removed
The clearest thing we learned is worth more than a feature list. We built email reminders for lease expiries — a scheduled job that mailed out warnings on a timer. Then we removed them and replaced them with a warning panel on the dashboard the team already opens every day.
Emailed reminders sound obviously right and are quietly wrong. They arrive whether or not the thing still needs attention, they arrive for people who are not the right person, and within a fortnight everyone filters them. A panel on the screen someone already looks at is seen, and it is current every time it is seen. We would not have known that from a requirements document. We only knew it because the system was in real use and we were still watching it.
Two other changes tell the same story. Roles and admin permissions were tightened after launch, not before — because it is only once real people are using something that you find the corners where somebody can reach further than they should. And the system later grew a whole second side for acquisitions, which was not in the original brief at all.
What it costs
Our published prices, which are the same ones on the Proprietary Database page: £7,000 to build and £100 a month to run, hosted and maintained. No per-seat charge, so a growing team does not cost more.
For comparison, the UK market typically quotes £10,000 to £30,000 for a bespoke build of this kind, which we cover with sources in our custom database cost guide. And if you want the ready-made version of roughly this system rather than a bespoke one, TenureBook starts at £295 a month and is live the day you sign up.
When we would tell you not to do this
A bespoke build is the wrong answer more often than it is the right one. Do not do it when your process is ordinary enough that off-the-shelf software already fits, when you are spending less than a few hundred pounds a month on software today, when the way you work is still changing week to week, or when nobody internally will own the system once it exists. That last one kills more projects than budget does.
We sell both a ready-made product and bespoke builds, so we have no reason to push you toward the expensive one.
What this case study deliberately does not tell you
Not how many properties they hold, not their rent roll, not their name. Those belong to the client. The figures on the screens on our work page are invented for the walkthrough and labelled as such, precisely so nobody mistakes them for a real portfolio.
We would rather publish a thinner case study that is true than a fuller one that is not. If you want to judge the work, look at the system — the screens are real even where the numbers are not.
If you are weighing this up for your own portfolio, tell us what you are running on now and we will tell you honestly whether a build is worth it.