Greenlight helps organisations move from intuition to evidence and from activity to impact. Platform 2.0 is the operational backbone that ambition now needs, and it has one job it can never fail at: protecting the deep, contextual, trusted data your whole value proposition rests on.
South Africa has more than a quarter of a million registered non-profits. Funding flows to many that cannot show what actually changed for the people they serve, while some genuinely effective organisations struggle to raise money because they have no credible way to evidence their value or connect with the right funders. Greenlight sits precisely on that fault line. It gives funders confidence that money follows results, and gives strong organisations the evidence they need to grow. Platform 2.0 is how that capability scales: infrastructure, in a very real sense, for improving the impact of the NPO sector across South Africa.
The track record backs it up: TGO has grown into a partner to 175+ organisations across South Africa and Sub-Saharan Africa, holding over 110,000 household-level assessments. The methodology is multidimensional: participants self-diagnose against red, yellow and green indicators, and baseline, second and third survey cycles reveal not only what changed but why, and whether it will last.
We have also read your ambition carefully, because it shapes the architecture. TGO is explicit that the goal is not to become the country's largest measurement organisation, nor simply to produce more reports and complete more surveys. The goal is to help organisations build the capability to improve their impact over time, inside a learning ecosystem where implementing organisations, funders, practitioners and other stakeholders all contribute to and draw from a continuous cycle of evidence, learning and improvement. A platform serving that ambition cannot be a reporting tool with a portal bolted on; it has to carry the whole ecosystem.
We also understand that Greenlight has deliberately evolved beyond measurement. Your investment case is clear that you are now a learning partner: trusted evidence is the beginning of a contracted, collaborative learning journey over an eighteen-to-twenty-four-month lifecycle, not the end of a reporting process. That is why the member journey, not the survey, is the primary organising structure of Platform 2.0, and why journey management cannot remain outside the platform in Airtable.
Finally, we understand the sector reality: member organisations operate under real financial and operational pressure, facilitators work in low-connectivity environments on modest devices, and users span a very wide range of technological comfort. A platform that is technically excellent but high-friction would fail your Joyful Journey principle just as surely as bad data would fail Trusted Data.
The heart of our case is simple. Platform 2.0 will stand or fall on data integrity and journey architecture. riivo arrives already inside Greenlight's data, already producing Greenlight's reports, and already tested as a partner when things got awkward. Our Discovery starts at week three, not week one.
Most open questions (anonymous surveys, iOS priority, multilingual, Power BI) are addressed in Sections 2 and 3; two we would pin down early:
Discovery has one purpose: to leave TGO holding three defensible artefacts. A validated data model and migration plan. An architecture that has been demonstrated, not just described. And a fixed-price build scope the board can commit to with confidence. We are rigorous where rigour de-risks the build, and iterative everywhere else.
We run an eight-week, three-phase Discovery, sitting at the efficient end of your eight-to-twelve-week window. We can compress the calendar because we are not learning Greenlight from scratch: we already know your data model, your report structures and your team. Where most vendors would spend weeks one and two orienting, we spend them validating.
A distinctive feature of our Discovery: we do not only produce documents. By week five we put a clickable prototype, including the journey configuration screens themselves, in front of your staff, members and facilitators, because your brief rightly demands that configurability is demonstrated rather than inferred. We design with AI-assisted tooling (Claude and Lovable), which is why a tested prototype fits inside an eight-week Discovery at all, and wireframes are tested twice, with real users, before anything is priced.
| Session | With whom | Produces |
|---|---|---|
| Kickoff, governance & success criteria | CEO, Heather, Kate, riivo leads | Charter, decision cadence, risk log |
| Member journey mapping workshops (x2) | Hub Admins, Member Journey Manager | As-is and to-be journey maps; stage-gate inventory |
| Member & facilitator voice sessions | 2-3 member Champions; facilitators; Training Ambassador | Friction map across user roles and comfort levels |
| Airtable structural deep-dive | Heather, Kate, operations team | Full inventory of views, fields, automations to preserve |
| Data landscape validation | Heather + riivo data engineering | Profiling of the MySQL estate against the June 2026 audit; dedupe rule candidates |
| Activity | With whom | Produces |
|---|---|---|
| Target data model & integrity rules | riivo, validated with Heather | Single-source-of-truth model; ID uniqueness, validation and audit design |
| Journey architecture working sessions | Hub Admins, Kate | Template, stage, gate and cohort model; configurability spec |
| Report generation architecture | Heather + riivo | Automation design for all survey and report types; time-to-report targets |
| Wireframes & clickable prototype | AI-assisted design: Claude, Lovable | Staff console, member portal, mobile flows and the journey configuration screens |
| User testing round 1 | Staff, Champions, facilitators | Scored usability findings feeding revision |
| Activity | With whom | Produces |
|---|---|---|
| Migration plan validated against profiled data | riivo data engineering | Entity-by-entity migration plan and risk assessment for the ~240GB estate, Python data and Airtable journeys, grounded in source profiling |
| Prototype refinement & user testing round 2 | Same user panel | Validated UX baseline for build |
| Build backlog & fixed pricing | riivo, reviewed with TGO | Full backlog of user stories with acceptance criteria, point-sized; fixed build price; change control |
| Critical path & release plan | riivo + TGO leads | Sequenced plan to 1 March 2028 go-live |
| Board-ready readout | Board, CEO, project leads | Full Discovery pack handover; go / no-go basis for Stage 2 |
Every workshop output lands in a single living specification, not a pile of slide decks. Journey maps become journey templates in the configuration model. Configurability scenarios become acceptance criteria. The prototype becomes the UX contract. The data profiling becomes migration rules with named owners. In week six we decompose the specification into a point-sized backlog of user stories, each with testable acceptance criteria, and price it. The result is the fixed scope, fixed price and critical path your brief requires: defensible because every line traces back to something your team saw, tested or signed off during Discovery.
In Discovery, UX goes deep enough to de-risk, not to decorate: journey and process maps for every role, low-fidelity wireframes for all primary flows, a clickable prototype of the highest-risk journeys (survey session lifecycle, report request, journey configuration), and two structured user-testing rounds across the full range of technological comfort. In the build phase, high-fidelity design is produced sprint by sprint from the validated wireframe baseline, with usability checks at each release. This keeps Discovery honest and the build fast.
Your proposed separation of Sales Journey, Programme Journey, cohorts and survey cycles is, in our view, exactly right, and it maps cleanly onto a configurable workflow engine. Discovery gives it a dedicated workstream: we model journeys as data (templates, stages, sub-stages, entry and exit rules, gates), then test the model by walking your staff through all six scenarios from your Discovery Input Pack on the prototype's configuration screens. Section 3 walks through each scenario in detail.
| Who | Involvement across the 8 weeks |
|---|---|
| Heather Jooste (Project Lead / Data SME) | Roughly one day per week, weighted to weeks 1-3 and 6-7 |
| Kate Bain (Systems & Integration SME) | Roughly one day per week, weighted to journey and Airtable workstreams |
| CEO | Kickoff, two checkpoint sessions, board readout |
| Hub Admins / operations team | Four workshops plus two testing rounds |
| Member Champions & facilitators | One voice session and two prototype testing rounds each (we schedule around their availability) |
TGO's brief commits dedicated resources, swift decisions and access to data and stakeholders; the plan above stays within that commitment.
riivo prices outcomes, not effort: we scope in build points, a measure of the size of a result rather than the time behind it, and every engagement in this proposal is fixed price. Our fixed fee for this Discovery is R165 000 excluding VAT. It follows our Discovery: Premium model, a senior, multi-stakeholder engagement producing a board-ready pack, extended here to eight weeks with a tested clickable prototype and a full user-story backlog because this project deserves them. In AI-accelerated delivery, the thinking up front matters more than the build that follows it; this Discovery is where the project is de-risked. Half is payable on commencement and half on handover of the artefacts, and if TGO proceeds to the build with riivo, a quarter of the fee (R41 250) comes back as a credit against the build. Duration is eight weeks from 1 September 2026, completing by 30 October 2026.
The pace is deliberate. The AI-accelerated build completes by mid-2027, months ahead of a conventional team; and since Airtable is already separate, the journey engine can go live and retire it in Q2 2027 without waiting for cutover. What sets the calendar after that is not our velocity: your team's absorption, training, migration rehearsals repeated until the reconciliation evidence is boring, and a cutover timed to survey-cycle boundaries. The window opens from October 2027; TGO picks the date, with 1 March 2028 the fully buffered ceiling.
What follows is our initial point of view, built from the brief, the Discovery Input Pack, the two audits and our working knowledge of your data. Discovery exists to test and refine it, and we hold it accordingly: firmly, but not preciously.
The June 2026 audits are unambiguous: the current database is structurally unsound and the platform fails at 6-10 concurrent users. We agree with your conclusion to rebuild, not remediate, and we would recommend a full technology change rather than working within the Spring Boot / Angular / MySQL estate:
| Layer | Our proposed direction | Why |
|---|---|---|
| Database | PostgreSQL, single well-architected store: Azure Database for PostgreSQL, or Supabase as a managed platform option | Strong constraint enforcement (unique IDs, foreign keys), row-level security, proven at hundreds of millions of rows. Supabase adds platform governance and managed auth for a modest subscription; Discovery weighs it against Azure-native |
| Backend & API | TypeScript service layer with a clean REST/JSON API | One API serves web, portal, mobile and the Python pipeline; API-first from day one |
| Web platform & portal | Next.js (React), mobile-responsive | Fast, accessible, WCAG-friendly, huge talent pool, no vendor lock-in |
| Mobile app | Expo (React Native) for a rebuild, or Flutter to evolve the current app | One codebase for iOS and Android either way; a rebuild keeps the whole stack TypeScript. Path confirmed in Discovery |
| Hosting | Microsoft Azure, South Africa region, auto-scaling, managed by riivo | Data residency for POPIA, auto-scaling kills the concurrency ceiling, and our Microsoft partnership keeps it well-governed |
| Delivery method | AI-accelerated engineering (Claude-based), human-reviewed, fully tested | More platform per rand; every line still owned by TGO, readable, documented and conventional |
And this is not a paper stack: SurgiFlow (Section 4) runs on it in production today. Nothing above carries per-user licensing, so facilitator growth never triggers licence cost; the recurring platform costs are hosting and, if selected, the flat Supabase subscription. Either way TGO keeps full governance and South African data residency. And any competent successor vendor could take the codebase over, which is exactly how IP ownership should feel.
Our stance: never build the new platform on the old data's assumptions. We design the target model first, from the business domain (participants, households, cohorts, journeys, surveys, indicators), with integrity enforced in the schema itself: unique participant IDs, foreign keys everywhere, mandatory audit columns, validation at point of entry. The legacy database is then treated purely as a source to be mined, cleansed and mapped into that model, never as a template for it. Performance is addressed structurally: composite indexing around real query patterns, read models for dashboards, caching (absent entirely today, per the audit), and pagination and streaming so a 3,000-survey export never times out again.
Configurability is your most important non-functional requirement, so here is our thinking against each of your six scenarios. The unifying principle: journeys, surveys, views, rules, notifications and roles are data, not code. Staff edit them through admin screens; nothing below requires a deployment. We have built precisely this class of engine before, most recently for a wealth-management client (delivered through a partner; named in conversation): triggers, stages and steps, with rules for which items carry over between stages and which must complete in strict order. Our recent survey design work for Nomios covered the other half: survey structures that hold up as they evolve.
| Your scenario | How our architecture handles it |
|---|---|
| Add a 'Pre-contracting' stage with its own task list and entry criteria, plus a filtered pipeline view | Journey templates are editable records: staff insert the stage, attach a task checklist and entry criteria in the template editor, then save a filtered view of members by pipeline stage. Existing journey instances are versioned so history stays intact. |
| Change a stage-advance rule to 'session closed AND data quality score above 80%' | Stage gates are rule expressions built in a condition builder (field, operator, value, AND/OR). Data quality score is a first-class computed field, so this rule is a two-minute edit. |
| Add a new household indicator without a code deployment, syncing to the mobile app | Survey definitions live in the database with explicit versioning. Staff add the indicator in the survey designer; the mobile app pulls definitions on sync. Versioning rules (which we define with you in Discovery) protect longitudinal comparability. |
| Create a staff dashboard view: members in Baseline Survey, sorted by days overdue | A view builder over journey and cohort data: pick columns, filters, sort, save, share. Days-in-stage and overdue flags are computed fields available to every view. This is the Airtable muscle memory, preserved natively. |
| Reminder 14 days after a session opens if not closed | A notification rule builder: trigger event, delay, condition, audience, channel (email now, WhatsApp later). Rules are records; staff create and pause them freely. |
| Create a 'Strategic Partner' role with read-only access to a defined cluster of organisations | Role-based access control with organisation-cluster scoping is configuration: staff define the role, set permissions to read-only, and attach the cluster. Every permission change is audit-logged. |
riivo built TGO's current Power BI geo-mapping and reporting dashboards, so this recommendation carries some self-awareness: move away from Power BI for Platform 2.0. It exists to compensate for what the platform cannot do, its data already disagrees with platform data, and it adds licensing, a sync surface and a second version of the truth. In the new platform, the movement map, Hub KPI views and reporting dashboards run natively against the single database, so the numbers on screen are the numbers in the reports, always. If a genuine self-service analysis need emerges beyond that, Discovery will size it on evidence; the requirement itself is answered natively, licence-free.
We favour Option A, full consolidation at go-live, with a safety net. Consolidating your scattered tooling into one platform is, in our view, the single biggest structural win in this project, and Airtable is the centrepiece of it. Our reasoning:
And to be unambiguous about the perimeter: everything moves. CRM, sales pipeline, report request management and support requests come across along with journey tracking, because the Sales Journey triggers Programme Journeys and belongs in the same engine. Retiring Airtable does not even wait for the platform cutover: the journey engine can go live ahead of it, with the few stage gates that depend on survey-session state fed one-way from the legacy platform, or confirmed manually where a feed is not worth building, until cutover completes the automation. Journey data itself never lives in two places.
We treat migration as an engineering project with evidence, not a weekend cutover:
POPIA is designed in, not audited in afterwards: consent status captured as data on every participant record (already one of your quality flags); data minimisation in the model; encryption at rest and in transit; role-based access with full audit logging; South African data residency; a documented breach process; operator agreements; and independent penetration testing before go-live. Aggregated movement insights are anonymised by design so cross-member views can never leak participant identity.
One codebase for iOS and Android either way; the real question is rebuild or evolve, and Discovery answers it. If the app is rebuilt, we would use Expo (React Native), which keeps the entire platform in TypeScript end to end; DAC Power, the offline-first field application we are building right now, is built exactly this way. If TGO prefers a substantial update of the current app instead, Flutter remains the right answer and we work within it. The real engineering work is not the framework; it is offline-first sync done properly: a local queue, conflict-safe upload, resumable transfer for photo payloads, and automatic sync so facilitators never have to remember to press a button. Discovery validates the path, and the iOS priority itself, against your actual facilitator device base.
One quiet failure of the current platform is that its knowledge lives in its provider: technical documentation was never maintained, so handover is now hard and slow. Our process makes that impossible for TGO. Documentation is generated as the build proceeds, not written up afterwards: technical docs, user guides and training artefacts are produced alongside the code, kept current release by release, and sit in a shared workspace TGO can open at any time. With the IP terms in Section 6 and a mainstream stack, TGO could hand the platform to any competent team at any point and lose nothing. The best proof of partnership is building as if you might leave, so you never have a bad reason to stay.
One note covers all of them: the platform ships AI-ready, with a Claude integration layer built in, so each idea lands as configuration, not a rebuild. The simplest example is already in your pack: journey stage transitions creating Asana tasks and firing notifications automatically, so your team's time shifts from administration to the relational work only humans can do.
Report narrative is manually written today and flagged as a future automation goal. As a Claude partner program participant, riivo would design the reporting engine so an AI drafting layer can propose narrative interpretation from the quantitative results, always reviewed and finalised by your analysts.
Rather than flagging duplicates and GPS gaps at reporting time, the mobile app and platform validate at capture: possible duplicate participants surfaced to the facilitator, GPS sanity checks, consent prompts. Bad data is prevented, not detected.
An AI-assisted translation workflow with community reviewer sign-off, built on the survey versioning model, lets Zulu, Xhosa and Afrikaans land in phases with natural language, at a fraction of traditional localisation cost.
The rebuild is the start, not the ceiling. Our Anthropic work lets us grow an internal AI ecosystem around TGO: knowledge bases holding your methodology and institutional memory, skills and plugins automating the routine work, assistants your team directs. The principle never changes: AI exists to leverage your people, so a team of ten can serve a movement of hundreds.
Every capability Platform 2.0 needs is battle-tested somewhere in riivo's portfolio: scale, workflow engines, migration integrity, apps in the stores, and the rebuild motion itself. The four cases below each prove one of them; the matrix that follows maps the coverage.
The Greenlight Office: automated report generationYour dataYour reportsIn production today
riivo designed and operates the automated preparation of Greenlight's baseline and impact reports, the deliverable your previous provider could not automate: extraction from the current platform, transformation against your methodology, templated generation of the full packs. The working knowledge of your data model that de-risks this whole project. 20-30pp report packs, generated Days → 0 manual effort per report |
TTT Financial Group: custom build and platform at scaleNamedReferencedLive metrics
TTT runs its operation on systems riivo built and still evolves: a Power Platform core, end-to-end case management, a client portal, and Tina, an AI assistant living in WhatsApp, grounded in TTT's knowledge base and live client records. First go-live in three months. 10,000+ clients served 879 Tina cases, first 10 days 72.7% resolved, no human Referee: Roscoe Dekker, CEO
|
Health Collective: migration verified to the recordMigrationReconciliation evidence
Continuous glucose monitoring data migrated from source through a staging virtual machine into Dataverse: reconciliation evidence on every pass, and a final cutover with every record individually accounted for. The same discipline, scaled with enterprise tooling, is what Greenlight's 240GB estate gets. 100,000+ records migrated Zero unaccounted loss |
SurgiFlow: TGO's exact journey, live on the stack we proposeBubble → Next.js + Supabase + ClaudeLive + scaling
Surgical Assistant's two-sided healthcare marketplace proved its model on Bubble; in 2026 riivo rebuilt it on the very stack proposed in Section 3, one of four such rebuilds this year, in service of a mission TGO will recognise: putting unemployed doctors back into theatre. 1,100+ vetted professionals 60+ active customers R11.7m+ paid to SA doctors Referee: AD Schoeman, co-founder
|
| Capability TGO needs | Depth | Where riivo has proven it |
|---|---|---|
| Platforms of comparable complexity, at scale | TTT Financial Group: 10,000+ clients on a custom-plus-Power-Platform build; a listed insurer's core distribution system (named in conversation) | |
| Workflow and journey engines | A configurable workflow engine (triggers, stages, carry-over and strict-order rules) for a wealth-management client via a partner; TTT's end-to-end case management | |
| Data migration and integration integrity | Health Collective: 100,000+ records, zero unaccounted loss; HR Department: 62 entities integrated with Xero via custom connections in one Dynamics app; legacy integration for the insurer above | |
| Client-facing apps, shipped to the stores | Teflon Connect (live events) and Everhot, both live on Apple and Google today | |
| Offline-first mobile | DAC Power, in build now on Expo (React Native), offline-first by design | |
| Bubble-to-AI-stack rebuilds | SurgiFlow, live at scale on the proposed stack after its 2026 rebuild, plus three further rebuilds this year; Platform 2.0 is this pattern at full scale | |
| Reporting, dashboards and survey design | TGO's own automated report generation; Nomios survey design; management reporting across the portfolio | |
| NPO sector, long-horizon stewardship | Fisantekraal Centre for Development: SharePoint migration and ongoing support | |
| Our own medicine | riivo's delivery runs on internal applications and a client portal we built ourselves |
battle-tested in production live and scaling on our AI stack in build now
A fair question from the board: much of riivo's delivered work runs on Power Platform or Bubble, so why does that qualify us for a custom build? Because the hard problems in Platform 2.0 are not language problems, they are architecture problems riivo solves constantly: configurable workflows and stage gates, multi-organisation security, staff-editable views, offline-sync capture, reporting automation. Power Platform and Bubble are professional workflow and configurability engines; years of building on them teaches a team how a configurable journey engine must behave, and the rebuild motion in the matrix above is how that experience now lands on our custom stack. Behind it all sits Saratoga, our part-owner, one of Cape Town's largest enterprise software development companies and an Andersen Consulting collaborating firm: senior review, QA capacity and continuity on call.
These clients have agreed to speak to TGO directly:
Most projects hit difficulty somewhere; the test is what the partner does next. We built an early version of a core digital system for one of South Africa's largest insurers (named in conversation only). As launch approached, it became clear the client's in-house data integrations feeding our system would not be ready: one internal developer carried that work, mid-Covid and hard to reach, and the go-live date could not move. The integrations were contractually not our problem; the failure of the project absolutely would have been.
NB Nic Bowman Senior Stakeholder · CEO Owns: accountability, partnership, board interface
CEO of riivo since 2020, after heading operations and product development at Icon Digital Consulting and four years in investment banking at Absa/Barclays. Microsoft-certified Solution Architect (PL-600) and Power BI Data Analyst; Claude certified architect since June 2026. |
FL Francois Lotter Delivery Lead Owns: end-to-end delivery, architecture, technical quality
Head of Delivery. A certified Bubble developer with 20+ delivered projects; in 2026 he led the build-out of riivo's AI Build competency and its governance. Four production systems have been rebuilt onto the AI-built stack this year under his lead. |
NL Natalia Luiz Project Manager Owns: cadence, plan, risk, releases, communication
Certified ScrumMaster (CSM, A-CSM) who, as Agile Delivery Lead, took a multi-tenant SaaS platform from MVP to live production, onboarding its first customers and doubling team velocity. BCom Honours, UCT. |
DG Dormehl Gertenbach Product Owner / Business Analyst Owns: workshops, spec, backlog, acceptance criteria
Joined riivo in 2025 from AgrigateOne, where he led the end-to-end integration lifecycle: complex data pipelines and data integrity across the fresh-produce supply chain. A former Dynamics 365 consultant with a BSc in Information Science; has led multiple successful riivo deliveries. |
LW Lungile Willie Quality Assurance Owns: test strategy, test packs, defect management, UAT
Senior Test Analyst with nine years of QA experience across insurance and wealth management, ISTQB certified, with a Master's in Information Technology. He owns riivo's test packs and defect discipline. | |
The people who run your Discovery lead your build; that continuity is part of what Discovery buys. If a key person must change, TGO hears first, meets the replacement, and pays nothing for the handover; project knowledge lives in shared artefacts, never in one head. Core delivery is riivo's own team, with two disclosed exceptions: pre-go-live penetration testing goes to a specialist third-party firm (the builder should not mark their own homework), and Saratoga can add senior engineering or QA capacity under riivo's direction. Nothing else is subcontracted without TGO's prior written consent.
One principle runs through everything below: we own the outcome. riivo commits to fixed prices; if work takes longer than planned, that is our cost, not yours.
Payment structure for Stage 1: 50% on commencement, 50% on handover of the Discovery artefacts. If TGO proceeds to Stage 2 with riivo, 25% of the Discovery fee (R41 250) is credited against the build balance, taking the net cost of Discovery to R123 750. All artefacts are TGO's property on final payment, whichever partner builds Stage 2: the pack is written to be buildable by any competent team.
Based on the brief, the Discovery Input Pack, both audits, and our existing working knowledge of your data model, our indicative order-of-magnitude for the full Platform 2.0 build is:
R2.7m to R3.2m excluding VAT for the complete Must Have scope: platform, member portal, iOS and Android mobile app, automated reporting engine, journey engine, full data migration, training and handover. Add the Discovery fee, net off its credit, and the full programme lands comfortably inside your R2.5m-R3.5m envelope.
How we got there. We decomposed the Must Have requirements into fifteen delivery areas and sized each in riivo build points, the same method that fixes the price after Discovery. The range covers all of it:
| # | Delivery area | What it covers |
|---|---|---|
| 01 | Platform foundation | infrastructure, environments, authentication and role-based access, monitoring, security baseline |
| 02 | Data model & integrity | the new schema, validation engine, full audit trail |
| 03 | Data migration | profiling, cleansing rules, rehearsals, reconciliation evidence |
| 04 | Journey engine | templates, stages, gates, cohorts, cycles, notifications |
| 05 | Survey management & designer | versioned definitions, no-code editing, mobile sync |
| 06 | Mobile app | offline-first field capture, iOS and Android |
| 07 | Reporting engine | automated generation across all survey and report types |
| 08 | Member portal | profiles, report access, survey history, resources |
| 09 | Staff dashboards & views | configurable KPI, pipeline and journey views |
| 10 | Integrations | maps, email, push notifications, Asana automation |
| 11 | Documentation & training | generated docs, user guides, onboarding flows |
| 12 | Structured testing | a written test pack per backlog item |
| 13 | UAT support | defect resolution through your acceptance rounds |
| 14 | Go-live & cutover | final migration, switch-over, rollback plan |
| 15 | Hypercare | post-launch stabilisation, handing into Momentum |
Points are anchored to what each area is worth in traditional delivery terms; our AI-accelerated engineering is what fits this scope inside your envelope at all. Priced conventionally, we believe this scope exceeds your ceiling, which is consistent with what happened the last time it was built down to a price.
Confidence and headroom. Confidence is moderate-to-high: high because we already know the data model, the report structures and the audits' findings first-hand; moderate because per-entity migration decisions, the depth of native analytics at launch and the report automation target belong to Discovery. If the fixed price exceeds this range we say so before you commit, drivers itemised. And because AI-native delivery changes our cost base rather than our quality bar, we expect room in the range to bring selected Should Haves, even early Phase 2 ambitions, into the launch conversation, explicit and priced.
You asked for our standard support model; we would go further. Our recommended shape: a fixed-price core build with formal change control, released first, then straight onto Momentum after roll-out, all within the stated envelope. From that point riivo owns support, tracks the metrics that matter (adoption, data quality, time-to-report), and responds to feature requests at speed, because the team that built the platform is the team evolving it. For TGO's size and roadmap we recommend Momentum: Grow. It replaces the static retainer you have today with a subscription that ships improvements monthly; Phase 2 never needs another RFP, its items simply become Momentum backlog. The hosting SLA is quoted with the fixed build price after Discovery.
Momentum: Launch
Lean start
R30k /mo · 4 pts
|
RECOMMENDED FOR TGO
Momentum: Grow
The core offering
R50k /mo · 8 pts
Steady, consistent delivery for a product that is genuinely growing.
|
Momentum: Scale
Serious growth
R100k /mo · 16 pts
|
All tiers exclude VAT and hosting; tiers step up or down with a month's notice.
Indicative hosting for the proposed architecture (Azure South Africa: auto-scaling application tier, managed PostgreSQL, storage, monitoring, backups, DR) is R8 000 to R14 000 per month excluding VAT, depending on the redundancy and DR posture chosen in Discovery. riivo manages hosting under an SLA quoted with the fixed build price; third-party API costs pass through at cost, no markup.
| Stage | Terms |
|---|---|
| Discovery | Fixed fee R165 000 ex VAT: 50% on commencement, 50% on handover of the artefacts. 25% of the fee (R41 250) is credited to the build balance if TGO proceeds with riivo. |
| Build | Fixed price set in Discovery, invoiced per completed milestone, never in advance. Each feature milestone completes in three signed steps: story sign-off, development, QC tested. Delivery milestones then follow for UAT, go-live and hypercare. No completed milestone, no invoice; formal change control governs any scope movement. |
| Ongoing | Momentum subscription monthly in advance; hosting monthly at the quoted SLA rate. If TGO prefers not to take Momentum, riivo offers standalone care and support packages so the platform is never unsupported. |
Confirmed, without reservation. On delivery and payment, TGO owns all code, schemas, designs, documentation and assets, including everything produced in Discovery. The stack is open technology with no proprietary riivo runtime, so ownership is real, not theoretical: any competent team could take it over.
If something we built does not work the way the signed-off specification says it should, that is a defect: we fix it at our cost for 90 days after go-live, no debate, no invoice. Critical defects (data integrity at risk, platform down, reports blocked) are worked immediately until resolved; the rest is prioritised with your team by impact. After 90 days, defect cover continues as part of Momentum for as long as the subscription runs. What warranty does not cover: new requirements, changes of mind, and third-party outages, which go through normal prioritisation. Data integrity issues are treated as critical at any time, because we understand exactly what trusted data means to Greenlight.
Everything in this proposal holds under the following assumptions; if any of them move, we say so immediately and re-baseline together.