Understanding the problem
My own reference sheet. Created in the format I prefer to understand the product, problem and identifying a solution. Not a deliverable.
The task
Big clients want Plentific's repairs and compliance data inside their own data warehouse, so they can join it to their other systems and ask their own questions.
Plentific has a warehouse, but it was built for internal analytics. It is not modelled for outsiders, not governed to the standard needed, and not properly separated client-by-client.
So there are two products: the internal platform work that makes a client-facing data product possible, and the client-facing product itself.
What Plentific does
When something breaks in a rented home, Plentific runs everything that happens next: logs the job, finds a contractor (the landlord's own team or a local firm from its marketplace), books the appointment, tracks the visit, collects the photos and paperwork that prove it was done, and handles the invoice. It does the same for legally required safety checks — gas, electrical, fire, damp and mould.
The workflow, and the data it leaves behind
One repair, start to finish. Who does what, who outside is involved, and what data gets created at each step. Everything in the "creates" lines is what a client wants in their warehouse.
Resident reports a broken boiler through the app or portal — or rings the contact centre, and an agent logs it
creates → work order · fault · free-text description · photos · linked to the home
Plentific diagnoses it, sorts it into a category and sets the priority
creates → category · priority · emergency flag · the Awaab's Law clock starts here
Plentific sends the job to the landlord's own in-house team, or out to marketplace contractors
creates → job leads · appointed contractor
outside → local SME firms, large contractors
Contractor accepts the job, or quotes for it
creates → quote · cost sheet · rates
outside → the contractor's own scheduling systems
Resident and contractor agree an appointment slot
creates → booking · scheduled date and time
Engineer attends the property and uses Plentific's mobile app to record what they do
(The app works offline — important because many properties are in basements, rural areas, or places with no phone signal. The engineer records everything on the phone, and it syncs to Plentific when they get signal back.)
creates → status changes (arrived → in progress → attended, or no access) · before, during and after photos · access notes
Engineer completes the work and signs it off
creates → completion report · signature · the full status history with timestamps
Contractor invoices. Landlord staff approve and pay it
creates → invoice · finance code · payment
outside → payment provider, the landlord's finance system
Inspector — running alongside all of the above — carries out the legally required gas, electrical, fire and damp checks
creates → inspection · every answer given · observations · certificate · remedial work orders
outside → certificate validation partner
All of that data has to come back out — today it can only leave three ways
- Dashboards inside the platform — fixed, cannot be changed
- CSV download — fixed columns, pulled by hand
- API into their housing system or CRM — built for workflow, not bulk
But it has to end up in
- Returns to the Regulator — Every year, landlords with 1,000+ homes must submit official reports to the government regulator. These have fixed deadlines (e.g. 30 June) and specific formats. Get them wrong or late and you are in trouble. Some of the numbers in these reports come from repairs data.
- Awaab's Law evidence — If a tenant complains about damp and mould, the landlord now has a legal clock ticking: investigate within 24 hours or 10 days depending on severity, send a written summary within 3 days. If they get sued or investigated, they need to prove they met those deadlines. That proof is timestamps in the repairs data.
- Board and committee reports — The people who run the housing association (the board, the audit committee) need regular reports: how many repairs, how fast, how much spent, any problems. These get presented in meetings and shape decisions.
- Joined to their own data — Plentific only knows about repairs. The landlord's other systems know who lives in each home, whether they pay rent on time, whether they have health conditions that make them vulnerable, and what the finance team has budgeted. The real questions need both — e.g. "are we slower to fix things for vulnerable tenants?" That question needs repairs data joined to tenancy data.
∴ The ask: "put it in our warehouse so we can do that ourselves."
Who the customers are
UK social landlords. Over 100 of them. Three types — but only the first type is asking for this.
| Type | What it is | Examples | How Plentific makes money from them today | Warehouse? | Asking for this? |
|---|---|---|---|---|---|
| Large housing association | Big not-for-profit landlord, tens of thousands of homes, has its own data team | Home Group, L&Q, Peabody, Notting Hill Genesis (66k homes), Southern Housing | Platform subscription across the whole property operation, plus extra modules, plus a cut when work is placed with marketplace contractors. Long multi-year contracts. Highest value accounts. | Yes | Yes — this is the demand |
| Council | Local government, owns council housing | Southwark, Lambeth, Lewisham, Basildon | Fixed-term contracts won through public procurement frameworks (Lewisham is a three-year deal). Subscription plus marketplace — the marketplace is Plentific's network of vetted local contractors (plumbers, electricians, roofers etc.). When the council needs a job done and cannot do it in-house, they post it to the marketplace and contractors bid or accept it. Plentific takes a cut of each job placed this way. | Sometimes | Mostly no. Wants compliance evidence, not analytics |
| ALMO | A company a council set up to run its housing. Manages homes it does not own | Northampton Partnership Homes | Often a single module rather than the full platform — NPH bought the repair diagnostic tool to feed their existing housing system. Smaller deals | Rarely | No. And ownership of the data is genuinely unclear here |
The money column is partly my inference from public contract notices and their marketing, not confirmed fact.
What their current money model means for pricing
How Plentific makes money today — a simple example
Imagine a housing association that manages 100 homes.
- The association pays Plentific a platform subscription — a fee to use the system, probably priced per home or as a flat annual deal. That is predictable recurring revenue.
- A tenant in one of those homes reports a broken boiler. The job gets logged in Plentific.
- The association's own in-house team cannot fix gas boilers, so Plentific sends it out to its marketplace of vetted local contractors. A plumber accepts the job.
- When that job is placed through the marketplace, Plentific takes a cut — a percentage of the job value, or a fixed fee per transaction.
So Plentific earns subscription + transaction fees. The more repairs that happen and the more that go through the marketplace, the more they make.
Why that matters for a data product
- Their revenue scales with work, not with data. Subscription plus a cut of jobs placed means Plentific earns more when more repairs happen. A data product would be the first thing that scales with data volume and query load instead. That is a brand new axis, and it is why the brief warns that good margin at ten clients can be no margin at a hundred.
- "We already pay for our data" is the objection I will definitely get — and it is half right. Clients pay a platform fee that includes dashboards and CSV downloads. The brief confirms data access is already "partly monetised", with some tiers and modules including more than others. So I am not pricing something new from zero. I am drawing a line inside something they already buy, which is harder.
- Today's data revenue is services revenue. Bespoke dashboards and one-off extracts get "quoted case by case". That means it is people's time, billed once, with no repeatability and no margin leverage. Turning services revenue into product revenue is the actual commercial goal here.
- Councils cannot easily be upsold mid-contract. They are on fixed-term procured deals bought through frameworks. Whatever I design has to survive being bought that way, or it only ever sells to housing associations.
Who owns what — the most important thing on this page
| Party | Pays? | Data about them? | What should the landlord receive about them? |
|---|---|---|---|
| Landlord | Yes | Partly — their properties, their staff, their spend | Their own operations data — they are the customer paying for this |
| Resident | No | Heavily — home, repair history, photos, vulnerability | With limits — Residents aren't asking for anything; they're not in this conversation. But the export is about them. So when the landlord receives data, what they get about residents should have limits — not full names where IDs would do, not vulnerability details unless truly needed, not photos of the inside of their home without good reason. |
| Contractor | Indirectly | Heavily — prices, quotes, bank details | Mostly no — third-party data |
| Plentific | — | Its marketplace pricing | No — that is its own advantage |
What data exists, and who wants it
| Area | What it actually is | Who wants it, and why |
|---|---|---|
| Repair jobs | Every job from reported to signed off. Includes a full history of every status change with timestamps | Everyone. This is the crown jewel — the status history is the legal timeline Awaab's Law is judged against |
| Safety and compliance | Gas, electrical, fire, damp checks. Inspection forms, answers, what was observed, follow-up work | Compliance director — proving compliance and defending against enforcement |
| Homes and equipment | Properties, blocks, estates, and the kit inside: boilers, lifts, fire doors | Asset team — deciding where to spend the investment budget |
| Money | Job costs, invoices, cost sheets, finance codes | Finance — spend per property vs budget, value for money |
| People | Residents, contacts, staff and their roles | Data team wants it to join to tenancy. Data protection officer wants it restricted. Highest risk data here |
| Communications | Messages to residents, and free-text notes staff typed | Compliance — proving the tenant got a written summary in 3 working days |
| Photos and documents | Before/during/after photos, certificates, signatures | Compliance — strongest evidence they have. Also photos inside people's homes |
| Reference data | The lookup lists: repair categories, status meanings, location types | Easy to forget, and essential — see below |
Plentific's data uses long ID codes, not words. A job does not say "gas boiler repair", it says
category_uuid: 23791438-f098...
Hand over the jobs without the lookup lists and it is like handing someone a hospital spreadsheet where every column is a barcode. Perfectly accurate, completely useless.
What clients have today, and why each one breaks
Clients already have three ways to see or extract their data. None of them do what the big associations actually need.
| Tool | What it is | Good for | Why it breaks for the warehouse ask |
|---|---|---|---|
| Dashboards and reports | Built-in screens inside the Plentific platform. Charts, tables, KPIs. Staff log in and look at them. | Day-to-day operations — "how many jobs are open right now", "which contractors are behind" | Fixed fields, cannot be changed. If the client's definition of "completed repair" differs from Plentific's — which it always does, because the Regulator's differs too — they cannot fix it. They see Plentific's answer, not their own. |
| CSV downloads | A button in the platform that exports a spreadsheet of jobs, invoices, etc. The client clicks it and gets a file. | Ad-hoc analysis — someone in finance wants to check something in Excel | Fixed columns, pulled by hand. Cannot be scheduled to run automatically. Cannot be joined to other data easily. No guarantee the columns will be the same next month. No audit trail. Useless as a proper pipeline source. |
| The public API | A programmer's interface. Another system (like the client's housing management system) can call it to read data out or write data in. For example: read job status from Plentific, or create a new work order in Plentific from the housing system. | Integration and workflow — keeping two systems in sync. "When a tenant reports a repair in our housing system, automatically create the job in Plentific." Or the reverse: "when a job is completed in Plentific, update our housing system." | Built for workflow, not bulk analytics. Designed for one record at a time, in real-time. To rebuild a full repairs table you would have to call it thousands of times — once per job, then once per booking, then once per invoice, etc. Slow, expensive, and Plentific pays the compute for all those calls. |
The pattern: all three are shaped by Plentific's definitions, but the client's questions are shaped by the Regulator's. That mismatch is the problem — not the transport mechanism.
Why shipping fast changes the schema — and why it does not have to hurt clients
Part one: why building features moves the data
Data structures shape the product. Change the product and the data moves with it. Six concrete ways:
| What the team does | What happens to the data | Plentific's real example |
|---|---|---|
| Ships a new feature | A new field or table appears to hold the new thing | uprn added to job locations, Sep 2026 |
| Makes a workflow more precise | A status list grows. What was one step becomes five | Bookings gained arrived, in_progress, attended, not_attended, no_access, cancelled in Feb 2026 |
| Renames for clarity | The same thing is suddenly called something else | Properties to Locations. Tenants to Residents |
| Splits or merges a concept | One column becomes two, or two tables become one with a type field | Blocks and Estates collapsed into Location Types |
| Refactors for scale or speed | Tables get reshaped. Nothing user-visible changes, but the underlying structure does | Not publicly visible, but the brief says internal structures change every week |
| Nothing — someone changes a setting | A new field or value appears with no code change at all | Custom fields can be created and their allowed values added or removed. So can tags, location types, asset types, asset classes and finance codes |
Other companies solve it exactly this way — including Plentific
| Company | How they hold a stable promise while shipping fast |
|---|---|
| Stripe | Every account is pinned to the API version it first integrated against. You upgrade when you choose to. Stripe ships constantly and old integrations keep working for years |
| Shopify | Dated versions released on a fixed quarterly rhythm, each supported for about a year. Developers always know how long they have |
| Salesforce | Many numbered API versions kept alive simultaneously, retired slowly with long published notice |
| Plentific | Already does this. Dated versions since 2020-01-01, which is still documented six years later. The current one, 2023-02-01, has held for over three years while the product shipped weekly |
What they are asking me for
My checklist.
Note: there are two different sets of four
Four registers — how to think
Product, engineering, commercial, governance.
The brief says a data product "sits across" all four and asks me to reason in all of them "rather than retreating into the one you find most comfortable". This is about not being one-dimensional.
Four areas — what to cover
1. Cost and commercial modelling
2. Technical considerations
3. Version and change control at their pace of shipping
4. Governance, security and data protection
Cover all four, unequal depth allowed, and tell them how I weighted them.
I want to go deep into version and change control
- The brief calls it "the part that quietly decides whether the product survives".
- It is the least reversible decision on the list. Once clients build pipelines on a schema and their security team signs it off, changing it is enormously expensive. The transport mechanism, by contrast, can be swapped later.
- It is where I have the strongest evidence — their own API shows dated versions:
2020-01-01,2021-10-28,2023-02-01. The current version has held for over three years while the product shipped weekly. They have already solved this problem once. - I think change control is a product decision (what goes in the contract), an engineering one (where the boundary lives and who owns it), a commercial one (what we commit to, what we refuse, and what we charge for stability), and a governance one (auditability, restatements, what a client reported last quarter).
Everything they asked for, as a checklist
| # | What they asked | What it really demands from me |
|---|---|---|
| 1 | Reason across product, engineering, commercial and governance. Go deeper on one and say why | Explicitly state my weighting on a slide. Deeper on change control, for the reasons above |
| 2 | Clients — mainly large housing associations — want to join our repairs and compliance data to their own. They ask for batch export: raw or lightly modelled, dependable schedule, a schema they can build pipelines against and trust not to break. Formats vary | Take a position on each of those words. How raw is "lightly modelled"? What does "dependable" mean in numbers? Which formats do I support and which do I refuse? And name the decisions I take versus the ones I defer — they ask for that specifically |
| 3 | The warehouse is not multi-tenant and is not client-ready | This is a hard blocker, not a caveat. Nothing ships to a client until tenant isolation would survive an external security review. It sets the first item on the roadmap for me |
| 4 | There is internal platform work and there is the client-facing product. Which one, or both, in what order? | An opinionated sequence with a reason. And critically: how do I get invisible internal work funded when on its own it delivers nothing a client can see? My best angle is that it is not new spend — it replaces manual extract work already being done at unmeasured cost, and it unblocks committed revenue |
| 5 | Pricing, given we carry the cost | Unit economics first: storage, compute, egress, and the people who keep it running. Then a model. Who pays when a client triples query volume or wants hourly instead of daily? And it must hold at 100 clients, not just 10 |
| 6 | The main concern: can the product keep moving while the export keeps its promises? | This is the whole case study in one sentence. My answer: yes, and they have already proved it once — via a versioned contract layer, a stricter definition of "breaking", a gate that catches configuration as well as code, and a deliberately narrow scope so the promise stays cheap to keep |
| 7 | What is the product, who is it for, what does the first shippable version look like, what comes after, and what is explicitly out of scope? They want a clear opinionated view they can argue with | Be opinionated and specific. Name the first version. Name what I am deliberately not building yet and defend it. Vagueness reads as not having decided, and they have said twice they want to argue with a real position |
| 8 | State my assumptions and name the trade-offs |
Questions I am not sure of and my assumptions
- How often does the internal warehouse refresh? This caps any freshness promise I can sell, whatever mechanism I pick.
- How many clients have actually asked, in writing? Versus one persuasive client. The brief warns me about "the loudest client".
- How many manual extracts have we already done, and how long did they take? This is my cost baseline.
- What is the warehouse built on? Build-versus-buy depends entirely on the answer.
- What did the Properties-to-Locations rename actually cost in support and migration? Best available estimate for what maintaining a boundary costs.
- How is the platform fee actually structured — per property, per user, tiered? I cannot price a data product sensibly without knowing what it sits next to.
- For ALMO clients, who owns the data — the ALMO or the council?
- What have we already promised in contracts? Data is "partly monetised" today, so some clients may believe they have already bought this.