Technical Consulting

03

Advice that the business can actually use

A consultant's real asset is not a slide deck; it is the ability to answer the question the business is actually asking — should we build this, buy that, fix this first, retire that, and how much will it really cost. We give advice grounded in operating systems, not in portfolio screenshots, and we argue from evidence the client can verify.

• The question under the question — 'pick our tech stack' usually means 'tell us we are not betting the company on a mistake'; we answer the sentence underneath, not just the literal one.
• Advice that would survive a competitor reading it — if our recommendation could not stand being scrutinized, it is not advice we should be giving; build-versus-buy is argued from your position, not our roster.
• Grounded in how systems really run — we have operated payments, loads, migrations and outages; the advice reflects how things behave at 3am and at scale, not how they look in a brochure.
• Sized to your situation — a startup and an entrenched enterprise need different answers to the same question; we do not hand the same prescription to both.
• Directable, not directive about your business — we are clear about what technology can and cannot fix; the business decisions stay yours, informed by ours.
• Presented as options with costs — every recommendation comes with a range, a trade-off and a reason, so 'what should we do' becomes 'which of these honest paths'.

The advice that changed a client's trajectory is rarely the clever one; it is the honest one. We say the honest thing even when it is not the thing that signs the larger contract — and that is precisely why the larger work tends to come later.

04

Build versus buy, argued from your situation

The two most expensive words in software are 'let's build it'. Sometimes building is right — sometimes the market genuinely has no tool for your core loop. But often the answer is buy, rent, or do less — and sometimes the honest answer is that the whole project should be smaller. We argue this with your money in mind, not our engineering hours in mind.

• 'Don't build this yet' is a real recommendation — if the market question is still open, the cheapest test of it is smaller than a full build; we will say so plainly.
• 'Buy it and move on' is a real recommendation — a commodity capability (auth, SMS, payments, maps) that is not your differentiator should generally be rented, and we say so even when building it would be our revenue.
• 'Fewer systems' is often the answer — consolidation pays: fewer integrations, fewer licenses, less ceremony; a setup with three tools doing one job each is usually a setup paying for architecture.
• The differentiator is the test — whatever makes you unlike your competitors deserves custom engineering; everything else should be ruthlessly commoditized.
• The cost of ownership is the real price — a free tool costs time, a cheap tool costs operations, an expensive tool can cost freedom; we compare total cost, not sticker price.
• The decision is written down — the build-versus-buy reasoning, the alternatives and the chosen path are documented, so next quarter's team understands why, not just what.

The recommendation that costs us the most work is the one clients remember longest. 'You do not need us for this yet' has started more of our great engagements than it has ended — because trust, once given, is the durable currency.

05

The architecture audit: the design that will crack at scale

Architecture problems are quiet. The design that handles a hundred users beautifully can crack at ten thousand in ways no single review comment predicts. An architecture audit reads the whole system as a connected whole — data, flows, concurrency, dependencies, failure modes — and reports what will bend, what will break and what will quietly cost forever.

• Whole-system reading — the audit looks at the data model, the flow between services, the queues, the jobs and the integrations as one organism, not screen-by-screen.
• Data flows are traced by hand — every major flow is walked from entry to storage to exit, and the writes that could conflict are mapped before they conflict in production.
• Concurrency is questioned hard — where two operations could overlap on the same row, queue or counter, the audit wants the lock, the idempotency or the proof — not a hope.
• Failure modes are named — what happens when a dependency dies, a job doubles, a callback is missed, a queue backs up; unnamed failure modes are how outages start.
• Scale assumptions are stress-tested — the point where the design stops working is estimated in users and transactions, and the client knows it before the growth does.
• Findings come with priorities and costs — every issue is ranked by likelihood, impact and the cost of fixing it now versus later; the report answers 'what do I do Monday'.

For payment clients the architecture audit includes a money-path pass the way a diver checks the tank. Concurrency on balances, idempotency on money actions and the callback verification loop are read line-by-line — because those are the lines that write or lose money.

06

The codebase review: the quiet shortcuts someone took

A codebase tells the truth about a product faster than any roadmap. We read the code a new senior engineer would inherit, and we report the shortcuts that will cost: the copy-paste that forked a feature, the bypass that skipped a check, the place where the code and the documentation secretly disagree.

• Read by intent, not by line count — we review the flows that matter (payments, auth, data writes) as deeply as they need, and skim the rest without pretending to fanfare.
• The bypasses are hunted — the direct write that skipped the service layer, the flag that skips verification, the environment check that turns off safety; these are the first-class findings.
• Duplication maps to divergence — where logic was copied, the copies are compared; three copies of a fee rule means two of them are wrong and we find which.
• Dependencies are audited for rot — outdated, abandoned or unmaintained libraries are listed with their risk, because a stale dependency is a future incident standing in line.
• The money logic is read line-by-line — for payment codebases, the fee calculation, the balance guards and the callback handling get the forensic read; the rest gets a professional one.
• Findings ranked by what they will cost — severity is expressed in money and time, not in adjectives; the client leaves knowing the order to fix things in.

A codebase review is not a performance of finding fault; it is an investment in the years the code will live. The quiet shortcuts someone took are the engine failures you cannot see until they are loud — we find them while they are still quiet.

07

The security review: the shortcut that was taken once

Security reviews are where the 'quiet problems' hurt loudest, because a security hole is an exploit before it is a finding. We review like an adversary with a checklist — identity, authorization, secrets, injection, enumeration, money paths — and we report prioritized vulnerabilities with the fix and the cost of each.

• Authentication and authorization mapped — who can do what, across every role and surface, including the admin paths a scanner rarely reaches.
• The money paths get the ruthless pass — rate limits, idempotency, callback verification, ledger immutability, balance guards; each is checked as a financial control, not a feature.
• Secrets are hunted — keys, credentials and tokens in code, in history, in config and in client bundles; leaked gateway or API credentials are treated as the emergencies they are.
• Enumeration is tested, not assumed — identical responses for 'exists' and 'does not exist' are verified, because enumeration leaks users to harvesters.
• Dependency and supply-chain posture — what the code imports, who maintains it, what it can touch; an audit reviews the supply chain, not just the first-party code.
• Findings with costs and fixes — each vulnerability ships with exploitation risk, remediation steps and the cost of fixing it now; fear without a plan is not a deliverable.

We have found vulnerabilities in code we did not write and code we did. The review is run the way we would want our own platform reviewed — because our own platform gets exactly this treatment before every release that touches money.

08

The tech debt assessment: real numbers on what shortcuts cost

Tech debt is not automatically bad — a pragmatic shortcut that let you ship is debt well spent. The problem is debt that is never measured, because unmeasured debt compounds in the dark. We assess what the shortcuts are actually costing in time, risk and velocity, and we price the repayment plan honestly.

• Debt measured in cost, not guilt — each shortcut is priced: what it costs per week in friction, risk or extended work, so 'should we pay it down' is an arithmetic question.
• The compounding is named — debt that grows with every feature (a brittle module everything touches) is ranked above debt that stands still (a script that runs once a month).
• The hidden debt is found — the undocumented assumption, the two systems doing one job, the manual step that only one person knows; these are debt with the price tag hidden.
• Repayment plans are staged and sequenced — we recommend the order that reduces risk and unlocks velocity first, not the order that satisfies aesthetics.
• Refactor-versus-rewrite is argued honestly — sometimes the honest answer is 'this module is fine, leave it alone'; rewriting is expensive theatre if the current shape works.
• The numbers survive the meeting — the assessment is written so a future team can update the prices and re-decide; debt is reviewed on a cadence, not atoning in silence.

The most expensive debt is the debt nobody priced. We turn 'we should probably refactor' into a number with a sequence and an owner — and sometimes the honest number is 'not yet'.

09

The cost analysis: the bill's escape routes

Infrastructure, tooling and people costs leak in ways nobody tracks — a service that grew past the free tier, three tools doing one job, a database sized for a spike that became the baseline. Cost analysis finds the leaks and prices the fix, so the bill stops being a monthly surprise and becomes a budget with reasons.

• Per-resource attribution — each line of the bill is mapped to a feature, environment or owner, so 'what is this for' has an answer and a human responsible.
• The tool-duplication audit — overlapping SaaS, a codebase service that was outgrown, a warehouse nobody uses; consolidation is a legitimately large saving that requires no code.
• Sizing versus reality — instances, tiers and limits are compared against actual usage; over-provisioning for a spike that never recurred is the classic bill leak.
• Unit costs on the platform — for payment and transaction products, the cost per transaction and per user is computed, because margins live in unit economics.
• Forecasts instead of eyebrows — current spend trends project next month and next quarter, so the budget conversation is scheduled, not triggered by the bill arriving.
• Savings with no risk to the product — every recommendation is classified by effort and risk, starting with the changes that save real money and touch nothing sensitive.

The one incident no alert fires for is the bill. A cost analysis is the observability the budget deserves — and the honest consulting answer is sometimes 'move to fewer, bigger things' rather than a cleverer cloud config.

10

Money-path consulting: our deepest ground

Not every consultant has operated a payment platform; we have. When a client's problem sits on a money path — M-Pesa or Daraja at home, PayPal, Stripe, PayStack, cards, bank rails, wallets, callbacks, reconciliation, a bill that will not balance — we audit it with the standards our own live platform is held to, and we say plainly what every money system must obey.

• Callback discipline is the headline review — is a gateway callback treated as a claim to be verified against the gateway's own status API, or as proof? The answer decides whether a platform is safe or lucky.
• Idempotency and 'exactly once' are read to the letter — can a retry, a redelivery or a double-tap cause a double-credit? We find the path where it can, then redesign it out.
• Concurrency on balances is verified, not assumed — row locks, atomic checks and the constraint that makes negative impossible are read on the actual money surfaces.
• Reconciliation is assessed as a system — does the ledger match the gateway statement daily, and does a mismatch surface as a workflow? If the answer is no, the platform is flying blind.
• The float and its separation are checked — customer money versus platform revenue, locked versus available, and the pots that must never co-mingle are mapped.
• The 'where is my money' path is stress-tested — can support answer a customer's question in minutes from the ledger and the gateway log? If not, that gap is a finding.

When a client's platform moves money, we bring the standards we run KodiiPay against — the verification loops, the terminal states, the immutability, the reconciliation. Advice about money from someone who has never been at 3am with a callback that will not confirm is just theory.

11

Feasibility and estimation: planning numbers, not marketing ranges

A budget estimate shaped by optimism is a contract with the future written in disappearing ink. We estimate with planning numbers — ranges that carry a plan and a risk list — so the client makes a budget decision with a real picture of the spread and the reasons for it.

• Estimates are ranges with reasons — a low, a likely and a high, each with the assumptions that move it; 'exactly two weeks' is a guess wearing a uniform.
• The riskiest parts carry the widest ranges — the API that might not exist, the flow users might not use, the integration nobody has tried; uncertainty is shown, not hidden in a confident round number.
• Feasibility is proven, not estimated — where the risk is 'does this even work', we prototype or spike it before we price the build around optimism.
• Estimates name the dependencies — what external systems, data and decisions must land for the number to hold; an estimate without its conditions is a lottery ticket.
• The estimate is a living artifact — as the build reveals reality, the plan updates; honest consulting never defends a stale number against fresh evidence.
• We price what matters, not what impresses — the core loop, the money path and the data get the careful estimate; the corner features get the honest 'less than this'.

Go/no-go evidence beats enthusiasm from the first deliverable. We would rather give a client a number they can bank on than a hero number they will relive at month six — and the planning range is the honest version of both.

12

The go/no-go: prototype the risk before the budget commits

Where the risk lives in the unknown, we test it small before the budget commits. A prototype of the risky part — the API that might not behave, the flow users might not use, the economics that might not reach the numbers — costs a fraction of a full build and converts a bet into a decision.

• The risky part is the prototype — not the logo, not the demo beauty; the uncertain integration, the untested flow, the assumption the whole plan leans on.
• Feasibility gets evidence — the risky API is actually called, the user flow is actually watched, the unit economics are actually computed; answers replace assumptions.
• The verdict is go/no-go, not 'pretty good' — the exit has two doors and a recommendation; the evidence decides, not the seniority of whoever likes the idea.
• It costs a fraction of the build — a spike is days; a full wrong build is months; the arithmetic of testing risk first is so lopsided it is not an argument, it is a reflex.
• The prototype leaves artifacts — the findings, the numbers and the decisions are written down, so the go/no-go evidence outlives the demo meeting.
• The no is worth as much as the go — ending a project before commitment on evidence is a successful engagement, not a failed one; we report it without a face-saving flourish.

The most expensive mistake in software is building the wrong thing well. Prototyping the risk first is the consulting discipline that makes that mistake cost a few days instead of a year — and a well-run no is a day's work that saves a fortune.

13

Tech strategy and the roadmap that can arrive

Strategy is the answer to 'where are we going and what do we retire along the way'. We help clients build a technology direction that names the destination, the sequence, and the systems that will be put out to pasture — because a roadmap that never mentions retirement is a roadmap to a junkyard.

• The destination is named — the product and technical state a few years out is described concretely enough that today's decisions can be checked against it.
• The sequence is honest about dependencies — what must be true before what; the roadmap is a path with load-bearing steps, not a wish list sorted by date.
• Retirement is on the roadmap — the systems, libraries and integrations that finish their lives are named with their sunset, so the junkyard does not get tidier by accident.
• Platform decisions are deliberate — build on a platform or own the whole stack is a strategy question answered with costs and constraints, not with fashion.
• The roadmap bends to evidence — a strategy that cannot be revised by real market and usage data is a monument, not a plan; we keep strategies genuinely open to learning.
• In-house versus vendor is argued per capability — for each part of the product we reason about build, buy, rent or retire, and the reasoning is written for the next decision-maker.

A consultant's strategy is only worth the decisions it can survive. We write strategy the way we operate our own platform: with names, costs and sunsets, so the roadmap has somewhere real to arrive.

14

The advisory relationship: we inform, you decide

The boundary of good consulting is drawn in one sentence: we inform, you decide. A consultant who oversteps into running the company, or a client who wants the consultant to be the scapegoat for a decision, is a relationship that will corrode. We hold the line, and it is the line that makes the advice trustworthy.

• Findings are delivered as information — priorities, costs and trade-offs, presented with the reasoning; the decision itself is owned by the client, always.
• We are an advocate, not a replacement — we strengthen the client's own team's judgment with evidence and clarity; we do not audition to take their seat.
• Disagreement is professional — when a client chooses differently, we implement their decision competently and keep the observation in writing; the relationship survives choices we advised against.
• The advice travels without motive — recommendations that also happen to sell our other services are flagged as such; when there is a conflict, the client is told.
• Board and founder context is respected — we translate technology into the language of risk, cost and timing for the people who answer to the business, not just the engineers.
• We are not lawyers or accountants — compliance, regulation and finance get the honest 'talk to the specialist' when the question crosses our lane; freedom from overreach is a kind of expertise.

Every engagement ends with the client more capable of arguing their own architecture. A consultant who leaves clients dependent on the consultation has failed; the relationship's goal is to make itself gradual — absent, because the client now holds the reasoning.

15

What consulting is not

The consulting industry's bad reputation is earned by its own confusions: reports nobody reads, advice that protects the vendor, sessions where the deck is the deliverable. We are explicit about what our consulting is not, so both sides start with honest expectations.

• Not outsourcing in disguise — consulting answers decisions; if the need is 'build it', we will say build it and price the build, rather than dress a team up as advisory work.
• Not a PowerPoint delivery — the deliverable is a decision that can be made: findings, priorities, costs and a recommendation; a deck with no decision in it is a conversation, not a product.
• Not status-quo protection — we will recommend change when change is right, including retiring a system that was flattering to someone's past decision; protecting the status quo is not a service.
• Not a guaranteed cheer — we say no to bad ideas with the same directness we use for good ones; a client who wants uniform agreement needs a mariachi band, not a consultant.
• Not free design work — honest scoping means some questions cost the decision-maker time; we size the engagement to the decision rather than the vanity project.
• Not a substitute for doing it — no amount of advice replaces operated experience; we are willing to stay and build, so the advice is never a stranger's opinion from a distance.

An hour of honesty at the start saves a year of polite fiction. We would rather tell you what consulting will not do for you than have you discover it after paying for it — the respect is mutual, and so is the work.

16

What a consultant should hand you

Whatever the surface form — an audit, a review, a strategy session, a board opinion — a consulting engagement should leave you with the same four things: a map of reality, a list of what matters most, a priced set of options and the reasoning to decide. If any of those four is missing, the work is incomplete.

• A map of reality — what exists today, how it behaves and where it is heading, stated without flattery and based on evidence you can check.
• Prioritized findings — what matters, ranked by the probability and size of the future cost, so the start-fix list is the right list.
• Costed options — for each decision, the honest choice set with the money, the time and the trade-offs attached, not a single towering recommendation with no floor.
• The reasoning — the assumptions and evidence behind each finding, written so a future decision-maker can re-derive or challenge it.
• A decision-friendly format — the work is structured so the client's answer ('yes to option two, with this scope') is a natural next step, not a re-read of the appendix.
• Knowledge that stays — the client's team can explain the findings themselves afterwards; consulting that keeps its learning in the consultant's head is a rental, not a transfer.

The test of a consulting deliverable is what happens the week after the meeting. If the client walks away able to decide, act and explain — the engagement worked; if they need the consultant back to interpret the report, it did not.

17

The independent second opinion

Founders, boards and investors sometimes need a view that has not grown in the same greenhouse. An independent read of a proposal, a vendor's claim or an internal roadmap is a legitimate and frequent part of our work — and it is exactly the kind of engagement where our honesty as a matter of principle is the product.

• The unincentivized lens — nobody sold the client the system being reviewed; the second opinion has no stake in whether it survives scrutiny, and says so.
• Vendor claims stress-tested — a platform's scalability, pricing path and lock-in are checked against the client's real shape; the talk of 'unlimited' is translated into a number.
• Internal plans challenged kindly — the roadmap the internal team loves is read for the assumptions it hides, with the same respect for its authors and the same rigor.
• For founders and boards alike — the audience that owns the decision gets it in their language: risk, cost, timing and what 'this could fail' would look like.
• The reasoning is portable — the second opinion is written so the client can carry it into their own rooms and meetings, not so it lives only in the consulting call.
• A short engagement for a long decision — the size is proportional to the question; a second opinion about a six-figure commitment is worth a morning, and is sold that way.

Every good decision survives a stranger's scrutiny. The second opinion is how a decision-maker hears a stranger's scrutiny in time to change the decision — cheaply, and before the money is committed.

18

Honesty about consulting itself

We are direct about what consulting, even honestly done, cannot do. Technology advice cannot rescue a product nobody wants, cannot fix a team culture with a report, and cannot guarantee the future of a system it does not operate. Naming these limits is not a weakness in the pitch; it is what separates advice from sales.

• The audited system changes — a review is a photograph of a moving subject; the findings expire, which is why we recommend a cadence rather than a one-time blessing.
• Analysis cannot replace ownership — a consultant can tell you what to fix; only the team that lives with the system can keep it fixed, which is why the team is part of every deliverable.
• The honest 'this needs operating' verdict — some problems are not review problems but running problems; the honest advice can be 'stop reviewing, run it properly first'.
• The future is genuinely uncertain — the gateway changes, the market moves, the team turns over; planning numbers include the uncertainty, they do not abolish it.
• We cannot be objective about where we also sell work — we flag the conflict and recommend the independent route when neutrality matters more than our engagement.
• Nobody is the expert in your house — the person who lives the business every day knows things no audit will find quickly; the best consulting treats that knowledge as evidence, not furniture.

The client who trusts a consultant completely is the client who stops thinking — and the client who stops thinking is the client who gets burned. We would rather have you challenge our findings than thank us for them.

19

How we consult — the shape of an engagement

Consulting engagements vary from an afternoon's second opinion to a quarter of architecture partnership, but the shape is stable: understand, gather evidence, map, probe, prioritize, price, present, hand the decision back. The exact steps below are how an engagement actually runs — and how one stays honest when it would be easier to please.

• 01 · Understand the intent — the business question, the decision in front of the client and the stakes; the engagement is sized to the decision, not the calendar.
• 02 · Gather the evidence — the code, the bills, the logs, the flows and the conversations; the audit starts from reality, never from the slide deck.
• 03 · Map the current system — what exists, how it behaves, who owns it and where its seams are; the map is the first deliverable and it must be checkable.
• 04 · Probe the risky paths — the money flows, the concurrency, the security surfaces and the cost leaks, read to the depth the risk demands.
• 05 · Prioritize honestly — findings ranked by future cost and likelihood, so the start-fix list is the list that saves the most money and the most nights.
• 06 · Price the options — each path with its range, its assumptions and its trade-offs; planning numbers, not hero numbers.
• 07 · Write the decision — findings, priorities, costs and reasoning documented so a fresh team can re-derive it; the thinking outlives the meeting room.
• 08 · Present and defend — the findings are walked through and challenged; a conclusion that cannot survive a hard question is a conclusion that needed the hard question.
• 09 · Hand the decision back and stay or go — the choice is the client's, always; if they want the build we build in the same spirit, and if not the advice stands alone as a finished, complete service.

You keep the analysis, the reasoning, the options and the decision. No consulting hostageware, no 'stay with us to understand what we found' — the value of the advice is that it is complete, portable and yours.

The toolchain

The technical consulting toolchain

Consulting is evidence work: the tools exist to read reality, price options and leave decisions with the people who own them. Every capability below is used across our audits, reviews, strategy and go/no-go work.

Lifecycle

The consulting lifecycle — from question to decision, handed back

Every consulting engagement, whatever its size, follows the same arc: understand, read reality, probe the risks, price the options, and leave the decision with the person who owns it. This is the shape of an honest engagement.

Closing

More than development

Consulting is the discipline of good decisions: reality read honestly, risks priced, options presented, and the decision handed to the person who owns it. We bring the perspective of people who also build and operate — our own live payments platform runs on M-Pesa and Daraja with cards, bank rails and international gateways behind the same discipline. That includes:

The best consulting is the consulting that makes itself gradual — present until the client's own team holds the reasoning, then stepping aside because they do.

We would rather give you an answer that costs us a contract than one that costs you a year — and the clients who test that claim find it is the first thing we deliver.