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." Boom, 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.

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 Went Component-Level Instead?

What if we generated the building blocks that organisations could assemble into exactly the software they need, right now, for this specific task?

The social sector doesn't need fewer tools. It needs the ability to create specific tools when specific needs arise, without requiring £100k custom development projects or forcing everyone onto generic one-size-fits-none platforms.

The startup opportunity is building a component library and assembly infrastructure specifically for just in time software and services.

Why Components, Not Complete Applications

Every organisation I work with has the same conversation:

"We need software that does [incredibly specific thing relevant to our specific community, in our specific context, integrated with our specific other systems]."

The options are:

1. Pay a fortune for custom development
2. Use a generic platform and compromise on 70% of what you actually need
3. Glue together five different SaaS tools and spend all your time managing integrations
4. Build it yourself and hope

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.

This is where it gets interesting. The social 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

Right now, that expertise stays trapped in their specific systems unless they decide to launch it into a sass product.

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.

The Startup 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 £50k 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, not months
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.

Not another platform. The infrastructure for rapid, context-specific assembly of exactly what each organisation needs.

The AI 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.

That's the interface layer the sector actually needs.