How we run engagements — so procurement and product stay aligned

Most software buying anxiety is not about frameworks. It is about whether the people you met in the sales call will still be in the room when scope gets messy.

We built Third River around that fear — on purpose. Below is how engagements actually run. No mystery process deck; the same model you will see on our About page, with the operational detail procurement and ops usually ask for next.

1. Listen & map

We start with whoever owns the decision — technical or not. Goals, constraints, users, integrations, compliance notes, and what “done” means in their language.

Output is not a 40-page requirements tomb. It is a shared map: what must be true, what is flexible, and what risks sit outside the build (data quality, partner APIs, internal change management).

If you cannot get decision-makers into that conversation, we say so early. Silent stakeholders produce surprise scope later.

2. Propose plainly

You get scoped options with trade-offs on cost, time, and risk — written so a non-technical buyer can stress-test them.

We will name what we would cut first if the budget tightens, what must stay for a safe launch, and where we would rather you buy a SaaS tool than hire us to rebuild one.

Jargon without a plain explanation is a red flag in our own writing. Hold us to that.

3. Build in the open

Working software every sprint. Shared backlog. Decisions written down. Access to the people writing the code — including co-founders on senior engagements.

Weekly demos are not theatre. They are the checkpoint where ops, product, and engineering correct course while change is still cheap.

If something is blocked on your side (credentials, content, approvals), we surface it in the same channel as the backlog — not in a month-end status PDF.

4. Hand over cleanly

Launch is not “ticket closed.” Docs, deploy ownership, environments, and a support shape that matches how you will actually run the product matter as much as the feature list.

Some clients want us for a defined build and clean exit. Others want ongoing maintenance. Both are fine — what we refuse is an ambiguous “we’ll figure support out later” that leaves you with a black box.

What this means for a scope call

Bring constraints. Timeline pressure, budget bands, must-have integrations (including M-Pesa where relevant), and who will own the product after launch.

We will leave you with clarity on feasibility and fit — including when another path is smarter. That is the job of the call, not a longer proposal.

Book a free scope call if you want that conversation with people who stay involved past the pitch.