The second of 8 ideas I set out in this blog at the end of 2025

If I was going to build a startup in 2026 (and I might) here's what I would be looking at: not generative dashboards, but generative components that let people (and especially the social sector) build exactly what it needs, when it needs it.

The 2023 Prediction

Back in 2023 (ish), I thought we'd soon stop building static dashboards and instead just talk to our data. Ask questions, get visualisations on the fly. "Show me referrals by area last month." Click, chart appears.

And we're sort of there. You can absolutely do this now. Claude and GPT can generate charts from data. Ask a question, get a dashboard, sort of.

Except it doesn't really work. Not because the AI can't generate the interface. But because our data isn't ready for that really. Our data is still messy, siloed, inconsistently structured, and locked in systems that can't expose it cleanly or easily. Try spinning a just in time dashboard while going in a death loop of microsoft admin privileges.

But as we move into 2026 I have begun wondering again about just in time interfaces beyond just dashboards, but as service components ready to be deployed.

What if we created a component commons?

Organisations need tools to do their work. Their current options for social purpose organisations to this point have mostly been:

1. Pay a fortune for custom development or really on volunteer/pro-bono support
2. Use a generic platform not built for this purpose and compromise on 50% - 70% of what you actually need (and probably some ethical compromises also)
3. Glue together five different SaaS tools and spend all your time managing integrations using zapier or Make or n8n
4. Build it yourself and hope (although increasingly I'm seeing people saying "could we just claude it?". I'm also increasingly seeing people say "we have this that is on claude but it's not quite working..."

What if there was option 5:

5. Assemble it from standardised, interoperable components built by organisations who've already solved similar problems

Not "here's a complete CRM," but "here's the component for intake forms, the component for case tracking, the component for outcome measurement, the component for referral coordination" and you assemble them into the specific tool your organisation needs.

Make use of the expertise we have.

The problem we have at the moment is that most enterprise software is designed for simple organisations, namely businesses. Yes businesses can be complex, but mostly there are controllable variables in businesses, predictable transactions/interactions, that are not present in social purpose organisations. To make software for these organisations you need to really understand how it works. Thankfully the social purpose sector has massive expertise embedded in specific contexts.

• A foodbank network that's solved complex inventory tracking in a crisis response context
• A youth service that's built brilliant engagement tools for young people
• A mental health charity that's developed sophisticated consent management for sensitive data

Currently that expertise stays trapped in their specific systems unless they decide to launch it into a sass product (which does occasionally happen - Upshot, In-form etc)

But, instead of every organisation trying to make their own sass, with all the challenges within that, what if each of these organisations could extract the component they've built and make it available for others to use in different contexts?

The foodbank's inventory component becomes useful for disaster response, community fridges, school uniform banks. The consent management component becomes useful across health, education, criminal justice sectors.

And what if there was a way to make use of these components when you need them?

The Opportunity

The Component Library for Social Purpose: A registry of pre-built, open-source components designed specifically for social sector needs. Not generic business tools, but components that understand:

• Complex consent requirements
• Safeguarding protocols
• Outcome measurement frameworks
• Partnership coordination
• Resource scarcity
• Community engagement

The Assembly Interface: An AI-powered tool that helps organisations describe what they need and assembles relevant components into a working prototype. "We need to track community garden plots, coordinate volunteer shifts, and report outcomes to our funder" → the system suggests relevant components and shows how they'd fit together.

The Contribution Protocol: A way for organisations to package their specific solutions as reusable components. You've built something brilliant? Extract the core functionality, generalise it just enough to be reusable, contribute it back to the commons.

The Adaptation Layer: Because no component will be perfect for every context, an AI layer that helps adapt components to specific needs. The foodbank inventory component needs to work for hygiene products instead of food? The AI helps adapt the logic while maintaining the core patterns.

What This Looks Like in Practice

A small advice charity serving refugees needs:

• Intake forms in multiple languages
• Case tracking with complex family relationships
• Document management with privacy controls
• Referral coordination with other services
• Outcome measurement for funder reporting

Traditional approach:

• Spend £x k on custom development, or
• Use a generic CRM and hack it into something sort-of-usable, or
• Keep using spreadsheets and/or clunky databases

Component approach:

1. AI helps them describe their needs in plain language
2. System suggests relevant components:
   • Multilingual intake forms (from a migrant support network)
   • Family relationship tracking (from a children's charity)
   • Secure document storage (from a domestic violence service)
   • Referral coordination (from the network protocol infrastructure)
   • Impact measurement (from a sector-wide outcomes framework)
3. Organisation assembles these into a working prototype in hours
4. AI helps adapt components to their specific context
5. They test with real users, refine, deploy
6. Six months later, they've built a novel component for supporting refugees through housing applications and they contribute it back for others to use

Why this (might) actually work now

Three things make this viable now that weren't five years ago:

1. AI can do the assembly and adaptation: The hard part isn't building components (developers can do that). It's helping non-technical people describe what they need and assemble components intelligently. LLMs are really good at this translation layer. Yes we will need to think carefully about the context layer, and constraining LLM's enough to make it work, but we have the tools to do it, and people, in both technical, data and service roles who could do this.

2. APIs and microservices are mature: The technical patterns for building interoperable components are well established. We know how to do this now.

Could this be the way to solve siloed data?

If components have standardised data structures, organisations gradually converge toward cleaner, more interoperable data. Not through mandated standards (which are really hard to make work in multi organisational settings), but through practical utility. "This component needs data structured this way" → "okay, let's structure it that way because this component is really useful." It's standards by stealth.

Bottom-up standardisation through shared components, not top-down mandates that everyone ignores.

What might this look like

In five years:

• A new charity can spin up working systems in days, not months
• Innovations built by one organisation are available sector-wide
• Small organisations have access to sophisticated tools previously only available to large ones
• The social sector has a thriving commons of shared components
• Organisations spend less time on systems and more time on mission
• Data gradually becomes more interoperable through practical use, not mandates

The infrastructure that makes this possible:

• Open source component library with social sector primitives
• AI-powered assembly and adaptation tools
• Clear protocols for contributing components back to the commons
• Quality standards and peer review for component reliability
• Governance by and for the sector, not by vendors

But why should we bother?

We are drowning in software debt and expensive systems that don't quite fit. We have technical debt we can't afford to fix and innovation locked in proprietary platforms.

We need infrastructure that lets the sector build what it needs, share what works, and adapt quickly when needs change. We don't always need another platform. Instead maybe we should focus on infrastructure for rapid, context-specific assembly of exactly what each organisation needs.

The AI of today can generate the interfaces. That's the easy part. The hard part is building the component library, the contribution protocols, the quality standards, and the governance structures. Components, not platforms. Commons, not vendors. Just-in-time assembly, not one-size-fits-none.

Oh and we probably need someone to actually focus on this, and fund it.