Engineering · From source to decision
Data & AI engineering for the decisions your team needs to make.
Based in Nairobi, Kenya. Built around African business contexts.
Move data safely. Connect daily operations. Agree the numbers. Put AI to work with human oversight. Explore each part below, including the architecture, outputs, and a small working example.
01 / Engineering service
Data migration
Changing systems should not mean losing your records.
Move from legacy databases and spreadsheets with a clear plan, checked records, and a controlled handover.
In an African business context
A SACCO moving member records into a new platform needs to preserve member IDs, balances, and history. We agree mappings, resolve exceptions, and reconcile totals before a cutover.
Illustrative scenario. Your design depends on your tools, budget, connectivity, people, and operating requirements.
What we hand over
- Source inventory and field mapping
- Migration runs with exception reports
- Record counts and balance reconciliation
- Cutover, rollback, and handover plan
From source to outcome
- 1Source records
- 2Field mapping
- 3Validation & exceptions
- 4Reconciliation
- 5Controlled cutover
Controls and ownership: Agree who can access the source, protect transfers, and rehearse the move. Cutover follows agreed validation criteria, with a rollback plan.
Skills & technologies
Common technologies for this work. We confirm the right stack and delivery scope with you during discovery.
- SQL
- PostgreSQL
- SQL Server
- Azure Data Factory
- AWS DMS
- Microsoft Fabric
- Schema mapping & conversion
- Match fields, types, and relationships between the old and new systems.
- ETL & change data capture (CDC)
- Plan the initial transfer and capture changes while systems remain in use.
- Data validation & reconciliation
- Check records, balances, duplicates, and exceptions before sign-off.
- Cutover & rollback planning
- Rehearse the switch and agree how to recover if checks fail.
Interactive example · sample data only
Map a sample member record
Choose the source field for the member ID. Check which records can move and which need attention.
Sample source records
- MB-001 · Amina · KES 4,000
- MB-002 · Kamau · KES 6,000
- Missing ID · Njeri · KES 3,000
02 / Engineering service
Data engineering
Your team should not spend every morning copying data.
Connect files, APIs, and databases with repeatable pipelines, quality checks, and clear ownership.
In an African business context
A retailer needs M-Pesa payments, bank exports, and shop sales in one place. A pipeline collects each source, checks for duplicate or incomplete records, and sends exceptions to the right person.
Illustrative scenario. Your design depends on your tools, budget, connectivity, people, and operating requirements.
What we hand over
- Source connections and refresh schedules
- Tested ingestion and transformation flows
- Quality rules and exception handling
- Monitoring, recovery instructions, and runbook
From source to outcome
- 1Files, APIs & databases
- 2Scheduled ingestion
- 3Quality checks
- 4Trusted storage
- 5Monitoring & alerts
Controls and ownership: Use scoped credentials and track data freshness. Plan retries around connectivity and source limits; failed records remain visible for review.
Skills & technologies
Common technologies for this work. We confirm the right stack and delivery scope with you during discovery.
- Databricks
- Apache Spark / PySpark
- Python
- SQL
- Microsoft Fabric
- Azure Data Factory
- Apache Airflow
- Delta Lake
- ETL / ELT pipeline development
- Load and transform data from operational systems into usable datasets.
- Lakehouse & warehouse design
- Choose storage and processing patterns for the workload and budget.
- Batch & streaming ingestion
- Match data refresh to the decision, from daily files to event streams.
- Orchestration, testing & monitoring
- Schedule dependencies, track quality, and recover failed jobs.
Interactive example · sample data only
Run a sample payment pipeline
Add a duplicate or a missing reference, then run the checks. Watch how invalid records are separated from the reporting data.
Start with 3 valid sample payments totalling KES 9,000.
03 / Engineering service
Analytics engineering
Finance and sales should not report different versions of revenue.
Turn raw data into tested models and shared metric definitions your reports can use consistently.
In an African business context
A distributor's sales dashboard includes unpaid orders while finance reports collected revenue. We agree what each metric means, model the rules, and document when to use each number.
Illustrative scenario. Your design depends on your tools, budget, connectivity, people, and operating requirements.
What we hand over
- Documented business definitions
- Reusable reporting models
- Tests for completeness and consistency
- Reporting layer and team handover
From source to outcome
- 1Operational data
- 2Clean data models
- 3Tested business rules
- 4Shared metrics
- 5Dashboards & decisions
Controls and ownership: Document calculation rules and access permissions. Trace each metric back to its inputs and agree owners for changes to the definition.
Skills & technologies
Common technologies for this work. We confirm the right stack and delivery scope with you during discovery.
- SQL
- dbt
- Power BI
- Microsoft Fabric
- Snowflake
- BigQuery
- Git
- Dimensional data modeling
- Build reporting models that connect business events and their context.
- Semantic models & metric definitions
- Define revenue, stock, and other measures once for consistent reports.
- Data tests, lineage & documentation
- Make report inputs traceable and catch broken assumptions early.
- Version control & CI/CD
- Review and test model changes before they affect business reporting.
Interactive example · sample data only
Make the revenue definition visible
Compare total order value with collected revenue, then apply one definition across both reports. All amounts below are sample KES.
Sample orders: KES 120,000. Collected: KES 90,000. Unpaid: KES 30,000.
Sales report: KES 120,000
Finance report: KES 90,000
Different definitions produce different numbers. Agree the question before comparing the reports.
04 / Engineering service
AI engineering
Routine searches and repeated tasks are taking time from your team.
Build AI workflows around approved information, tested outputs, and human decisions where they matter.
In an African business context
An agricultural supplier wants staff to find delivery and returns rules quickly. A document assistant retrieves approved policy passages, shows its sources, and sends uncertain cases to a person.
Illustrative scenario. Your design depends on your tools, budget, connectivity, people, and operating requirements.
What we hand over
- Workflow scope and approved data sources
- Tool connections and access controls
- Evaluation cases and failure handling
- Human review steps and operating guide
From source to outcome
- 1Staff question
- 2Access & retrieval
- 3Source-grounded draft
- 4Evaluation & human review
- 5Approved response
Controls and ownership: Define what the system may read and do. Test unsupported questions, require sources, log failures, and keep sensitive actions behind human approval.
Skills & technologies
Common technologies for this work. We confirm the right stack and delivery scope with you during discovery.
- Python
- REST APIs
- n8n
- Microsoft Foundry
- Amazon Bedrock
- Retrieval-augmented generation (RAG)
- Ground answers in approved documents using retrieval and vector search.
- Agent workflows & tool integration
- Connect models to useful tools with explicit permissions and limits.
- Prompt design & evaluation
- Test answer quality, source grounding, latency, and cost against agreed cases.
- Deployment & human oversight
- Monitor behaviour and route uncertain or consequential actions to a person.
Interactive example · sample data only
Try a source-backed answer
Choose a question from this scripted example. See the source, the answer, and the review step. This demonstration does not call an AI model.
Sample policy · section 2
Unopened items may be returned within 7 days with a receipt. Delivery times are confirmed when an order is accepted.
One decision is enough to start.
We agree scope, success checks, responsibilities, and handover before work begins. A Decision Lab pilot can turn one focused organization problem into a tested workflow with a named owner and a measured result.