Dataloom
A Data-as-a-Service platform tackling data silos among mid-sized SMEs in East Africa.
Project Overview
Dataloom (formerly the Action Intelligence Platform) starts from a specific, researched problem: mid-sized SMEs in East Africa generate data across many disconnected tools — POS systems, spreadsheets, messaging apps, paper logs but have no layer that turns that scattered data into usable intelligence. Dataloom is being built as a subscription DaaS product that connects to those existing sources and surfaces consistent, queryable insight.
The Problem
SMEs don't lack data they lack a way to see it as one thing. A sizeable share of organizational software goes unused or disconnected from other systems, and semantic inconsistency (the same concept — 'customer,' 'sale,' 'stock' meaning something different in each tool) makes even basic reporting unreliable without manual reconciliation.
This project is early-stage and pre-revenue. It's being developed in parallel across two tracks: an application to the AI Factory native.builder hackathon (August 2026) for funding and visibility, and a Moonshot accelerator application, so the current build prioritizes a credible architecture and a sharp problem thesis over feature completeness.
Target Users
Mid-sized SMEs in East Africa (roughly 20–200 employees) that run on a mix of digital tools and manual processes, and whose leadership currently makes decisions without a unified view of their own operational data.
Goals
- Prove out a data-ingestion approach that can normalize inconsistent schemas from common SME tools without heavy custom integration work per client
- Package the offering as a subscription DaaS product rather than a one-off consulting engagement
- Build a pitch and technical narrative credible enough for hackathon judges and accelerator reviewers evaluating an early-stage, pre-revenue product
Challenges
- Designing for semantic inconsistency across data sources without assuming every client will adopt a single canonical schema
- Positioning a pre-revenue, one-month-old product honestly to accelerators while still making a compelling case for its trajectory
- Scoping a system architecture that is realistic to build in a hackathon timeframe (August 3–10, 2026) while still reflecting the product's real long-term direction
Proposed Solution
The current architecture separates ingestion (connectors that pull from common SME data sources), a normalization layer (mapping inconsistent field names and formats onto a shared internal schema), and a query/insight layer exposed to SME users as a straightforward dashboard rather than a raw data tool.
System & Technical Architecture
SME data sources (POS, spreadsheets, messaging exports) → ingestion connectors → normalization layer (schema mapping, semantic reconciliation) → unified data store → insight/query layer → client dashboard.
Key Features
- Multi-source ingestion designed around common SME tooling
- Schema normalization to resolve semantic inconsistency across sources
- Subscription-based DaaS delivery model
- Dashboard-first presentation aimed at non-technical SME owners
Technical Decisions
Positioned semantic inconsistency handling as the core differentiator, not just ingestion breadth
Many tools claim to 'connect your data' — the harder and more valuable problem is reconciling what that data actually means across sources, which is where most SME reporting silently breaks down.
Framed the product honestly as pre-revenue and early-stage in accelerator materials
Overstating traction to reviewers who evaluate many applications erodes credibility fast; a clear, honest stage-appropriate pitch reads as more trustworthy than inflated claims.
Testing Strategy
At this stage, validation is concentrated on the research and problem-definition side (a completed report on data silos among East African SMEs) rather than full system test coverage, since the ingestion and normalization layers are still being built out.
Security Considerations
Architecture assumes credential-scoped, per-client data isolation from the start, given the product handles operational business data across multiple independent SME clients.
Results & Outcomes
Dataloom is pre-revenue and approximately one month into active development at time of writing. A completed research report, pitch materials, and initial architecture exist; a production ingestion pipeline is not yet built. [Placeholder: update with hackathon/accelerator outcomes once known.]
Lessons Learned
- A sharp, well-evidenced problem statement (backed by real research, not assumption) is what makes an early-stage data product pitch credible
- Naming the specific mechanism of failure — semantic inconsistency, not just 'siloed data' — makes the value proposition concrete instead of generic
Future Improvements
- Ship a working ingestion + normalization MVP for the native.builder hackathon
- Pilot with a small number of SME design partners
- Expand connector coverage based on pilot feedback
Want to talk through how this was built, or a similar problem you’re facing?
Get in touch