John Karanja
Hard work in · honey out Open to new projects

I help turn complex ideas into dependable systems.

I'm John Wainaina Karanja a.k.a @qwainaina on the interwebs, a product and systems lead. I help founders untangle difficult technology decisions, map the risks and plan the next useful step. Start with a focused architecture review; take the findings into a build when the direction is clear.

Explore architecture reviews See my work
Find me as @qwainaina
PythonTypeScriptNode.jsReactFastAPIPostgreSQLSQLiteRedisnginxDockerCI/CD
Chapter one · who I work with

For founders at a fork in the path.

You may be planning a product, inheriting a complicated system or deciding whether to add an AI feature. Before taking the next path, it helps to know what is sound, what is uncertain and what deserves attention first.

Crypto and web3 products

Wallets, payments, rewards and on-chain data: make the flows and failure cases understandable before extending them.

Finance and back-office automation

Connect records, checks and human decisions so routine work is easier to trace and review.

AI features with clear boundaries

Define the permitted sources, evaluation checks and human fallback before depending on an assistant.

A steady hand through the work

  • A clear brief. We agree the decision, scope, inputs and deliverables before work starts.
  • Plain answers. Findings separate what the evidence shows from assumptions and open questions.
  • Visible progress. We agree review points and explain any effect a change has on cost or timing.
  • Clear responsibility. I lead the engagement. Any implementation or specialist contribution is agreed explicitly.
Chapter two · a map before the next move

Architecture reviews

Find the weak joints before you build further.

A focused review for a founder or product owner who needs a clearer technical decision. We examine one application, one critical user journey and its immediate integrations, using an agreed set of materials.

Bring the question

  • What are you trying to achieve?
  • Where is the system fragile or hard to change?
  • Which decision is holding the next step back?

A diagram, known incidents and relevant test or code evidence help establish the scope. Share only material you are authorised to provide.

Leave with a practical map

  • An annotated current-state diagram.
  • Prioritised findings with evidence and explicit unknowns.
  • Recommended changes, trade-offs and an implementation brief.
  • A readout and one factual-clarification pass.

Fixed scope. Agreed fee. Clear handover. We confirm the questions, inputs and calendar slot before starting. You can take the findings to your own team; implementation is a separate decision.

This is a bounded technical review, not exhaustive code inspection, penetration testing, a financial audit or certification. Payment-flow checks, AI-feature readiness and technical due diligence can be scoped as separate reviews.

Discuss an architecture review
Chapter three · the honey pots

Systems I have helped shape

Different systems, shared lessons: make the flow clear, account for failure and give people useful controls. These examples describe my product and delivery work, including collaborative development. Private work is described by capability; the honey is the intended benefit, not a promised result.

01Public example · trivia and rewards

Nyukia

A trivia product combining learning, scoring, leaderboards and cryptocurrency reward workflows.

HoneyA learning experience that connects game progress with a traceable reward process.

Game logicWithdrawal statesReconciliation
Explore NyukiaTaste it here

The hard part

A withdrawal can have an uncertain outcome when a connection fails. The design needs a way to claim a request before sending it and reconcile uncertainty before another attempt.

The approach

Shared game and scoring logic, account and referral flows, and withdrawal-state controls. The work illustrates why a payment needs a clear lifecycle, tests and a human reconciliation path.

02Web3 · subscription service

On-chain wallet and token intelligence

A subscription-product design that brings wallet and token activity into a more understandable research view.

HoneyA clearer path from blockchain activity to research, with payment confirmation treated as a separate control.

The problem

On-chain data is public but unreadable for most people, and crypto payments are easy to fake if you trust the browser.

The approach

Indexing and analysis components, subscription and payment-confirmation flows, and explanatory interfaces. The design separates source data, interpretation and access decisions.

Data provenancePayment confirmationAccess rules
03Crypto · infrastructure

Proof-of-work mining pool and apps

Mining-pool and application work exploring how contribution, block construction and rewards fit together.

HoneyMake reward allocation inspectable and reduce reliance on an opaque payout process.

The problem

Different payout designs place different responsibilities on the operator. Those responsibilities need to be understood before deployment.

The approach

Pool components with multi-output block-reward construction, alongside application and device integration work. This is a system-design example, not a mining-return claim.

Share accountingReward constructionDevice integration
04Finance · automation

Finance and automation back-office

Record-processing and coordination tools for bookkeeping, deadlines and operational review.

HoneyKeep source records, reconciliation questions and human actions connected.

The problem

Several companies, many bank and mobile-money accounts, and filing deadlines that are easy to miss and expensive to get wrong.

The approach

Statement-processing and double-entry components, source-evidence links, reconciliation checks and operational views. These support review; they do not replace an accountant or certify the books.

Source recordsReconciliationHuman review
05Property · advisory

Property advisory platform

A content-led advisory platform with a source-grounded assistant and enquiry workflows.

HoneyHelp people find relevant information and reach a human when a question needs judgement.

The problem

Buyers ask the same questions at all hours, and a chatbot that makes things up is worse than no chatbot.

The approach

Shared content sources, publication filters, response checks and enquiry handoffs. Grounding and guardrails reduce risk; they do not make generated answers infallible.

Content groundingResponse checksEnquiry handoff
06Education · voice

Voice-first language tutor

Voice-first language-learning work with a reviewable content pipeline.

HoneyKeep practice material connected to its sources and review status.

The problem

Generated language material needs linguistic and cultural review before learners depend on it.

The approach

Speech interfaces, spaced-repetition components and a pipeline that separates candidate material from content admitted for learning. Learning gains are not claimed.

Speech workflowsContent reviewPractice design
07Data · signals

Market-signal engine

Research and scoring tools that organise observations and support historical evaluation.

HoneyMake assumptions and evidence easier to inspect before making a decision.

The problem

Signals are easy to produce and hard to trust.

The approach

Data-collection, scoring and historical-comparison components. A backtest is a method of evaluation, not evidence of a profitable live strategy.

Source trackingScoringHistorical evaluation
Taste the honey

A small taste of the interaction.

Try a short bee quiz here, with no sign-up or prizes. For Nyukia's current game and reward rules, visit its own site.

Loading…

Chapter four · from map to making

How a project runs

A review gives you a map. If you want help taking the next steps, we agree the implementation separately and keep the work in manageable pieces.

  1. 1
    Scout

    We agree the goal

    A short call and a written brief: what success looks like, what must never go wrong, and what's out of scope.

  2. 2
    Build the comb

    I design the structure

    The data, the moving parts and the risks, on one page you can read. You approve it before any building starts.

  3. 3
    Fill the pots

    Reviewable pieces

    Small slices with agreed checks and review points. Changes to scope are discussed with their effect on effort and timing.

  4. 4
    Seal the honey

    A handover you can rely on

    Agree release checks, recovery steps, documentation and an open-items list. Ongoing support is scoped when needed.

Chapter five · the journey so far

Engineer, entrepreneur, educator

My work connects product direction, technical design and practical explanation. The thread is the same: understand a difficult system well enough to make the next decision clearer.

  1. Product & delivery

    From a business question to a workable plan

    Leading requirements, workflow design, integration planning and delivery review across software and data products.

  2. Blockchain & education

    Making difficult ideas understandable

    A background in blockchain consulting, executive briefings and conference programmes, connecting technical questions with business decisions.

  3. Software & operations

    Learning from the work behind the interface

    Experience spanning software and database delivery, web services and business operations informs the questions I ask about reliability, ownership and handover.

Chapter six · the foundations

The rules I build by

A hive holds together because its structure matters. These principles guide how I frame a review and assess a build.

One source of truth

Identify the authoritative record and track where derived information comes from.

Check everything at the door

Validate inputs and settings at the boundaries, and define how the system handles rejection.

Account for uncertainty

Design for duplicates, timeouts and reconciliation. An unclear result needs investigation, not a blind retry.

Tests decide "done"

Agree observable acceptance checks. Distinguish a passing component test from a verified user outcome.

Small, reversible releases

Prefer bounded changes with explicit release checks and a tested recovery plan.

Measure, don't assume

I trust the bank, the blockchain and the live site, never a system's opinion of itself.

Chapter seven · questions by the fire

What people ask before we start

How do we start?

Send the decision you need to make, a short description of the system and your deadline. We establish fit and agree a written scope, fee and delivery slot before work begins.

What do you need from me?

A decision-maker, the agreed materials and time for the scheduled readout or review points. Use authorised, redacted records; do not send passwords or production credentials.

What if we change our minds halfway?

We compare the change with the agreed scope and discuss its effect on effort, fee and timing before proceeding.

How do you charge?

Architecture reviews use an agreed fixed scope and fee. Implementation is quoted separately. Payment or milestone terms are agreed before work starts; no rates are published here.

What happens after the work?

For a review, you receive the findings, priorities and a readout. For implementation, we agree documentation, handover and any ongoing support in the brief.

What I don't do: I don't write or audit smart contracts, train AI models from scratch, or give investment advice. I design around those, and work alongside the specialists who do.

The last chapter · say hello

What is the next decision your system needs?

Pull up a log. Tell me what you are building, what feels uncertain and when you need a decision. We can start with an architecture review or scope a different engagement.

Discuss your brief on Upwork
@qwainaina on