01What you asked for
Two inputs shaped everything: your written brief of 27 May, and your dashboard review of 4 June. Nothing in the build is speculative — every screen traces back to one of them.
dates per unit
→ Tenant
against contract
Your 4 June review — what you told us to keep, and to drop
| Keep / add | Where it landed |
|---|---|
| 5-stage merchant funnel, ending at unit handover from main contractor | RDD Operations — top strip |
| Priority work queue with delay drill-down + feedback field | RDD Operations — queue |
| Cut plans received | Exception strip |
| Lease-out by phase = NTCs ÷ units in phase | Executive Overview — hero |
| Leasing shown as NTC and Heads of Terms only | Executive Overview — phase bars |
| Handover back-planned from opening, with your buffer rule | Executive Overview — back-planning table |
| Forecast is the authoritative roadmap, not target | Opening roadmap |
| Drop | Status |
|---|---|
| Leasing position panel | Removed |
| Turnover risk | Removed |
| Opening look-ahead | Removed |
| "Next 4 weeks" strip | Removed |
| "12 signed off" metric | Removed |
| GLA / spaces / revenue for senior management | Removed |
| Bug: phase filter missing related tenants across phases | Fixed |
Your three "dream" items — CM contract review, PD base-build programme, IFC drawings — are held for the document register in Stage 4. They are the reason this is a verification tool, not a snag list.
Anything above that is wrong, out of date, or needs qualifying — something we kept that should have gone, something dropped that you want back, or a change of mind since June.
Saved and exported with the section 05 answers — use Copy all answers or Download as .md there.
02What's built — live now
Two dashboards, running on 635 real ARCA South units extracted from RDD's own Merchant Monitoring workbook. This is not a mock-up with invented numbers — every figure on screen is your data.
Both open live in a browser — nothing to install, no log-in. Each dashboard has its own link, so either can be sent on its own.
03What your own data already says
These numbers were not typed in. They fell out of the workbook the moment it was loaded. This is the argument for the tool — the information already exists in RDD, it just cannot be seen.
The funnel · 635 units
The exceptions
142 units are already trading, so handover plainly happened — but the workbook has nowhere to record it. That is the single gap between what RDD does and what RDD can evidence. It is also exactly the thing you need if you are going to hold CM to contract.
Also visible on load: 39% leased out (201 NTC + 40 Heads of Terms against 622 leasable), 51 units opening in the next 90 days, 8 already behind on opening, and a forecast peak of 100 openings in May 27.
04Where we are — honestly
This is a working prototype, not a system. It is deliberately read-only. The purpose of today is to agree that the picture is right before anything is built that is expensive to change.
Built and live
- Real data spine — an import that reads the Merchant Monitoring workbook and produces a clean, auditable unit record. Repeatable, not a one-off paste.
- Two dashboards — Executive Overview and RDD Operations, to your 4 June specification.
- Exception engine — every "late" is derived from your target and actual dates, not entered by hand.
- Priority work queue — filterable by phase, level, parcel, status; searchable by tenant or unit.
- Design system — a single consistent house style across every screen and every future export.
- Hosted — live on a URL, loads in under a second, nothing to install.
Not built yet — and deliberately so
- Editing and writes — nobody can change a date in the tool yet. It reads the workbook.
- Log-in — no accounts, no Ayala single sign-on, no permissions.
- The full unit record — design submission, MEP, delay notices and close-out are in your TSR format but not yet in the data model.
- Documents — no cut plans, LODs, IFC drawings or contract sections attached to units.
- Inspections and snags — no joint inspection capture, no snag register, no photos.
- Excel export and multi-mall — one mall, no export button.
- Alerts — nothing emails you when a date slips.
05What we need from you
Eleven items. Seven are decisions only RDD can make, two are data, two are about the path. Nothing below is a big piece of work for you — but the build stalls without them.
A · Product decisions blocking Stage 2
The queue is currently sorted by delay count. If the real priority is "openings inside 90 days" or "base-build handover late", the whole screen changes.
Phase, level, parcel and status are in. Anything missing that you would use daily?
The single most valuable answer here. The day it is complete, RDD stops maintaining two things.
Determines the permission model. Getting it wrong means either RDD is blocked or another team's data gets overwritten.
Decides whether onboarding a mall is a service we perform or a screen you use.
Small, but it is the hero metric and it should read in RDD's own language.
Right now excluded and storage rows are hidden by default. Confirm that is correct, or the denominators are wrong.
B · Data
Unblocks Evo City live in the tool. This is the last input needed; loading it is a day's work, not a build.
Tells us whether the tool reads a file, or eventually replaces it.
C · The path
All three are workable. They lead to very different build orders, and building the wrong one wastes months.
Sets the timetable everything else back-plans from.
Your answers are only on this computer until you send them. One press opens an email to hello@stuartdigital.io with everything you have typed already in the body — check it over and hit send.
If your mail client does not open, use Copy and paste into a message to hello@stuartdigital.io — same thing.
06Build plan
Seven stages. Each one ends in something you can open and use, and each one is gated by your sign-off before the next starts. Durations are working time from go-ahead, and assume RDD feedback inside five working days.
07What you get, what you own
Set out plainly, before anyone asks — what Ayala ends up holding, and what it does not. Fees and contract terms are deliberately not in this pack; they follow once the scope is agreed.
What Ayala gets
- A perpetual, non-exclusive licence to use Handoverr across Ayala-owned and Ayala-operated malls. No per-seat charge, no cap on users.
- Hosted, maintained and supported, on Ayala's own cloud account.
- All data exportable to Excel, CSV or JSON at any time, without asking.
- Quarterly review with RDD, and a defined route for changes.
What Ayala owns outright
- All of the data. Unit records, tenant information, dates, snags, photos and every uploaded document. Ayala's, unconditionally, from day one.
- The domain and the accounts. Registered in Ayala's name, on Ayala's card, from the start.
- The right to take a full copy of the data and walk away at any time, for any reason.
What Stuart Digital retains
- The underlying platform code and the reusable components behind it. Ayala licenses the product; it does not buy the toolkit. That is what keeps this a fraction of the cost of a bespoke build.
- The right to license Handoverr to other operators — never with any Ayala data, configuration or branding in it.
How it is supported and changed
| Item | What happens |
|---|---|
| Support | Defect correction, security patching, platform upgrades and management of the hosting environment. |
| Releases | Scheduled release cycles through the year, with a quarterly review alongside RDD. |
| Changes after go-live | An agreed allowance of development time each quarter, drawn down against changes RDD asks for — so a small change does not need a new conversation each time. |
| New modules | Anything materially outside the agreed scope is scoped and agreed separately, and always before work starts. |
08"What happens if Stuart disappears?"
A fair question, and the right one to ask before signing anything. It deserves a structural answer rather than a reassurance. There are six, and any three of them alone would be enough.
Key-person risk is real and should not be argued away — it exists with any small supplier, and it exists with a large one too, in the form of an account manager who leaves. What matters is whether the risk is contained. Here it is contained by the fact that Ayala owns the data, owns the infrastructure, already holds the source and the access to it, has documentation as a deliverable, and can take the code over on terms agreed at the outset. The worst realistic case is that Ayala hands a documented, ordinary codebase running on its own cloud account to another developer. That is an inconvenience, not a system failure.
The comparison worth making: with an incumbent platform vendor, none of the above is typically true. The data lives on their servers, the source is never available on any terms, and if the product is discontinued or repriced there is no exit other than a full replacement.