DEV Community: Oluwajuwon Omotayo

[Boost]

Oluwajuwon Omotayo — Mon, 29 Jun 2026 09:49:21 +0000

Oluwajuwon Omotayo

Jun 29

I Spent Months Building the AI Governance Layer Africa Was Missing. Today It Launches.

#showdev #agents #ai #opensource

5 min read

I Spent Months Building the AI Governance Layer Africa Was Missing. Today It Launches.

Oluwajuwon Omotayo — Mon, 29 Jun 2026 09:48:33 +0000

TL;DR

comply54 is now live: an open-source AI agent compliance framework built specifically for African regulated industries
It enforces African law at runtime, before your agent acts — not after an audit finds the violation
21 policy packs across 12 jurisdictions: NDPA 2023, CBN controls, NIMC Act 2026, NFIU-AML, POPIA, Kenya DPA, and more
Works with LangChain, LangGraph, CrewAI, and AutoGen via one import
Violations return the exact law, section, and penalty — not a vague error message
100% offline. Full audit trail. Apache 2.0.
Website: comply54.io | Repo: github.com/comply54/comply54 | Product Hunt: producthunt.com/products/comply54

The problem I kept running into

I build AI products in Lagos. Over the past year, I kept running into the same gap.

AI agent frameworks like LangChain, LangGraph, CrewAI, and AutoGen are exceptional at giving agents capability. Memory, reasoning, tool use, multi-agent orchestration. They are well-designed, actively maintained, and widely adopted.

None of them knows what the Central Bank of Nigeria says about transaction thresholds. None of them knows that Nigeria's NIMC Act 2026 prohibits retaining NIN data after a verification completes. None of them knows that the NFIU requires a Currency Transaction Report within 24 hours for transactions above a defined threshold.

This is not a criticism of those frameworks. They were built for general capability, not jurisdiction-specific compliance. But it creates a real problem for anyone building AI agents that operate in African regulated industries.

The agent can transfer money, access customer records, store identity data, and make financial decisions, all correctly from the framework's perspective, and still violate the law in ways that carry fines in the tens of millions of naira and criminal liability for responsible individuals.

Every team building in this space is solving this problem on their own, from scratch, in ways that drift and accumulate technical debt. That is the infrastructure gap comply54 exists to close.

What comply54 does

comply54 is a runtime policy enforcement layer for AI agents. It sits between your agent's decision to act and the tool execution that carries it out.

Before any action runs, comply54 evaluates it against the applicable policy packs and returns one of four decisions:

allow — proceed
audit — proceed but log with full regulatory context
escalate — pause and request human approval
block — prevent execution and return the exact violation with citation

When a violation fires, the response is not a generic error. It is a structured object containing the regulation name, the specific section, the penalty clause, a unique audit ID, and the remediation guidance. Your compliance team can produce it to a regulator. Your engineering team can write tests against it.

from comply54 import ComplyEngine

engine = ComplyEngine(jurisdictions=["NG", "ZA", "KE"])

result = engine.evaluate(
    action="transfer_funds",
    context={
        "amount": 6_500_000,
        "currency": "NGN",
        "customer_tier": 2
    }
)

print(result.decision)      # "block"
print(result.regulation)    # "CBN NIP Framework 2023"
print(result.section)       # "Schedule 2, Tier 2 Transaction Limits"
print(result.penalty)       # "Regulatory sanction, licence review"
print(result.audit_id)      # "cmp_01J3X..."

For JavaScript and TypeScript developers, the same API is available via the npm package:

import { ComplyEngine } from "comply54";

const engine = new ComplyEngine({ jurisdictions: ["NG", "KE"] });

const result = await engine.evaluate({
  action: "export_customer_data",
  context: {
    destination: "us-east-1",
    dataCategories: ["personal", "biometric"],
    customerCount: 15000
  }
});

// result.decision === "block"
// result.regulation === "NDPA 2023"
// result.section === "Section 25 — Cross-border Data Transfer"

Framework integrations

comply54 ships integration adapters for the four major agent frameworks. The goal is that adding compliance to an existing agent should take minutes, not days.

LangGraph:

from comply54.integrations.langgraph import comply54_node

graph = StateGraph(AgentState)
graph.add_node("comply54", comply54_node(engine))
graph.add_edge("agent", "comply54")
graph.add_conditional_edges(
    "comply54",
    lambda state: state["comply_decision"],
    {"allow": "tools", "block": END, "escalate": "human_review"}
)

CrewAI:

from comply54.integrations.crewai import Comply54Tool

compliance_tool = Comply54Tool(engine=engine, jurisdiction="NG")
agent = Agent(tools=[compliance_tool, ...other_tools])

AutoGen and LangChain follow the same pattern with their respective adapters.

What is covered: 21 policy packs, 12 jurisdictions

Every policy pack ships with the full regulatory citations embedded. Here is what is live today:

Nigeria (7 packs)

NDPA 2023 — data residency, consent, cross-border transfer controls
CBN Transaction Controls — tiered KYC limits, NIP thresholds, agent banking rules
NIMC Act 2026 — NIN data prohibition post-verification, retention controls
NFIU AML/STR — CTR thresholds, structuring detection, velocity controls
BVN/NIN Protection — exposure blocking, log sanitization, verification gating
POS Geo-Fencing — terminal location controls, cross-state transaction rules
CBN Open Banking — consent validation, data minimisation

South Africa (2 packs)

POPIA — special information, cross-border adequacy, responsible party audit
FSCA AI Conduct — suitability controls for financial AI recommendations

Kenya (2 packs)

KDPA 2019 — transfer restrictions, sensitive data, data minimisation
CBK Digital Credit — credit scoring controls, disclosure requirements

Regional and additional (10 packs)

ECOWAS cross-border transfer rules
Rwanda, Ghana, Ethiopia, Tanzania, Uganda, Botswana, Mauritius, Egypt data protection

Why 100% offline matters

comply54 evaluates entirely in-process. No network call is made during enforcement. No third-party API is consulted.

This matters for three reasons.

First, latency. A compliance check that adds 200ms to every tool call is a compliance check that engineers will route around. In-process evaluation adds single-digit milliseconds.

Second, reliability. A governance layer that requires a network call to function will fail when the network fails. That is the worst possible time for your compliance layer to go offline.

Third, data sovereignty. In jurisdictions with strict data residency requirements, sending decision context to an external service to evaluate compliance may itself be a compliance violation. Offline evaluation avoids this entirely.

The audit trail

Every evaluation — allow, audit, escalate, or block — generates a structured audit entry:

{
  "audit_id": "cmp_01J3XKRM...",
  "timestamp": "2026-06-29T08:42:11.203Z",
  "action": "transfer_funds",
  "decision": "block",
  "regulation": "CBN NIP Framework 2023",
  "section": "Schedule 2, Tier 2 Transaction Limits",
  "penalty": "Regulatory sanction, licence review",
  "jurisdiction": "NG",
  "agent_id": "payment-agent-v2",
  "session_id": "sess_8f2k...",
  "context_hash": "sha256:4a9c...",
  "evaluation_ms": 3
}

The context_hash is a SHA-256 of the sanitised evaluation context — PII is never stored in the audit log, only its hash. This satisfies the NDPA's accountability requirements without creating a new data protection liability.

What comes from the earlier work

comply54 did not appear from nowhere. The policy corpus builds directly on work I have been doing in public over the past few months.

The African regulatory policy pack I contributed to Microsoft's Agent Governance Toolkit — which was merged into microsoft/agent-governance-toolkit as PR #3077 — is the upstream source of the policy logic in comply54. The agt-policies-nigeria repo, which covers nine African countries and ECOWAS in OPA/Rego format, is the foundation that comply54's Python and TypeScript implementations are built on.

If you contributed to, starred, or used any of those earlier projects, comply54 is the production-ready version of that work.

What is next

The roadmap includes sector-specific profiles for fintech, healthtech, insurtech, and government AI deployments. The @comply54/adapter-eve package for Vercel's Eve framework is in active development. Support for additional East and West African jurisdictions is planned based on community interest.

The project is fully open source under Apache 2.0. Issues, PRs, and regulatory corrections from practitioners with real compliance domain expertise are the most valuable contributions.

Discussion

Two questions I genuinely want input on from this community:

First, if you are building AI agents for regulated industries outside Africa — in US healthcare, EU financial services, or similar — what does your compliance layer currently look like? Are you building it from scratch, using an existing tool, or deferring it?

Second, if you work in Nigerian or African fintech and have spotted a regulatory gap in the policy packs, I want to hear about it. The most valuable thing a compliance practitioner can contribute is a citation: which regulation, which section, which agent action pattern it should govern.

If comply54 is useful, an upvote on Product Hunt today would mean a lot. And a star on GitHub helps other developers find it.

Thank you for reading.

I Built a Policy Enforcement Layer for Vercel's Eve Agent Framework. Here's What I Learned About AI Governance the Hard Way.

Oluwajuwon Omotayo — Mon, 22 Jun 2026 11:59:37 +0000

TL;DR

Vercel's Eve (2.2k stars, actively developed) is a filesystem-first framework for building durable backend agents — but it ships with no governance layer
I built eve-policy, an open source policy enforcement library that wires into Eve's needsApproval and execute lifecycle with four-tier semantics: deny, escalate, audit, allow
The most interesting design challenge: Eve's needsApproval is synchronous and session-less, while execute is async with full session context — which forced a two-phase evaluation model
Built-in profiles include OWASP Agentic Top 10 (2026) and a financial services baseline covering USD/NGN/KES CTR thresholds
Fail-closed by default: no matching rule means deny, not allow
Repo: github.com/kingztech2019/eve-policy · npm: npmjs.com/package/eve-policy

Why Eve needs a governance layer

Vercel's Eve is a framework for building durable backend agents — filesystem-first, TypeScript-native, deeply integrated with Vercel's infrastructure. You define an agent as a directory of files: instructions.md, tools/, skills/, channels/, subagents/. It compiles to inspectable artifacts, exposes a stable HTTP protocol with sessionId and continuationToken, and manages the full lifecycle of agent runs.

It is a genuinely well-designed framework. Eve thinks carefully about durability, composability, and the operational reality of running agents in production.

What it does not ship with is a governance layer.

That is not a criticism. Frameworks generally do not dictate compliance policy — that is a product concern, not a framework concern. But it creates a gap that anyone building a real AI agent with Eve will eventually hit.

If your agent can call a transfer_funds tool, who decides whether a ₦6.5 million transfer requires human approval? If your agent has a subagent that can write to a data store, what prevents that subagent from calling tools it should not? If your agent handles BVN data, how do you ensure it never appears in an audit log?

These are governance questions. They do not belong scattered across individual tool implementations — that creates drift. They do not belong inside the agent loop — that couples your business rules to the framework. They belong in a dedicated layer that sits between Eve's lifecycle events and your tools' implementations.

That is what eve-policy is.

The design challenge: Eve's two-phase lifecycle

The most technically interesting part of building eve-policy was figuring out how to fit governance into Eve's lifecycle correctly.

Eve exposes two lifecycle hooks on every tool:

needsApproval(ctx) — called synchronously before the turn completes, to decide whether to pause execution and wait for human approval. The context at this point is minimal: you have the tool name and the tool input, but no session yet. This hook must return a boolean synchronously — you cannot await anything here.

execute(input, ctx) — called asynchronously when the tool actually runs. By this point, the full session context is available: session.id, session.auth, session.parent (whether the caller is a subagent), and the complete turn history.

This split forced a two-phase evaluation model in eve-policy.

Phase 1 (approval time): Input-based controls fire in needsApproval. Does the amount exceed a reporting threshold? Does the input contain a card PAN pattern? Does the tool name match a blocked pattern? These questions can be answered from the tool input alone — no session needed, evaluation stays synchronous.

Phase 2 (execution time): Session-aware controls fire in execute. Is the caller a subagent? What is the principal type? Is this an already-approved tool? These questions require ToolContext.session, which is only available in execute.

The same policy evaluates twice, but the context it has access to is different each time. This means a rule like "escalate financial writes from subagents" will see isSubagentCall() return false in needsApproval (no session yet) and true in execute (session available). The first evaluation handles the approval decision; the second handles the execution decision.

Here is what that looks like in the evaluation flow:

Eve lifecycle                    eve-policy evaluation
─────────────────────────────────────────────────────

  turn starts
       │
       ▼
  needsApproval(ctx)  ──────►  evaluatePolicy(policy, approvalCtx)
       │                            input-based rules only:
       │                            amountExceeds, fieldMatches,
       │                            toolNameIs, ...
       │  escalate? → true
       │  otherwise → false
       │
       │  [human approves if needsApproval=true]
       │
       ▼
  execute(input, ctx) ──────►  evaluatePolicy(policy, executeCtx)
       │                            session-aware rules now available:
       │                            isSubagentCall(), principalTypeIs(),
       │                            alreadyApproved(), ...
       │
       ├── deny?     → throw PolicyDenialError  (tool never runs)
       ├── escalate? → run tool, write audit entry
       ├── audit?    → run tool, write audit entry
       └── allow?    → run tool

The key insight: governance decisions on the hot path must never block on I/O. All rule match predicates are synchronous by design. Async work (audit logging) runs fire-and-forget after the decision is made.

Installation and quick start

pnpm add eve-policy
# or
npm install eve-policy

Requirements: Node.js >= 18, Eve >= 0.10.0

import { definePolicy, withNamedPolicy } from "eve-policy";
import { deny, escalate, audit } from "eve-policy/rules";
import { amountExceeds, isSubagentCall, toolNameIs, and } from "eve-policy/rules";
import { FileAuditLogger } from "eve-policy/audit";

// Define your policy
const transferPolicy = definePolicy({
  name: "transfer-controls",
  version: "1.0.0",
  rules: [
    deny("no-self-transfer",
      ctx => ctx.toolInput.source === ctx.toolInput.destination,
      "Source and destination accounts cannot be the same"),

    escalate("ctr-threshold",
      amountExceeds("amount", 10_000),
      "Exceeds $10,000 CTR threshold — compliance review required",
      { riskLevel: "critical", owaspRisks: ["ASI02"] }),

    escalate("subagent-financial-write",
      and(isSubagentCall(), toolNameIs("transfer_funds")),
      "Financial writes from subagents require human approval",
      { riskLevel: "critical", owaspRisks: ["ASI03"] }),

    audit("all-transfers",
      toolNameIs("transfer_funds"),
      "All fund transfers logged for compliance"),
  ],
});

// Wrap your Eve tool — one line, drop-in replacement
const safeTool = withNamedPolicy(
  "transfer_funds",
  transferTool,
  transferPolicy,
  { auditLogger: new FileAuditLogger("/var/log/agent-audit.jsonl") }
);

// Use it in your agent exactly as before
// Eve calls needsApproval and execute automatically

withNamedPolicy returns a new ToolDefinition — same shape, same interface, fully compatible with Eve. The governance layer is invisible to the rest of the system.

The four effects

Every rule has an effect: deny, escalate, audit, or allow.

Effect	`needsApproval`	`execute`	Audit
`deny`	`false`	throws `PolicyDenialError`	always
`escalate`	`true`	runs tool if approved	yes
`audit`	`false`	runs tool	yes
`allow`	`false`	runs tool	opt-in

Rules are evaluated in declaration order. First match wins. When no rule matches, defaultEffect applies — and the default is "deny", not "allow". A governance layer with no matching rules should not silently permit execution.

If you want allow-by-default with specific restrictions, set defaultEffect: "allow" explicitly. This forces you to make the intention clear rather than discovering it by accident.

Composing policies

compose() is how production policies are built. It flattens rules from multiple component policies and applies deny-wins semantics for the default effect.

import { compose } from "eve-policy";
import { owaspTop10Policy, financialBaselinePolicy } from "eve-policy/profiles";

const myAgentPolicy = compose(
  owaspTop10Policy,        // 20 rules covering ASI01–ASI10
  financialBaselinePolicy, // CTR thresholds, sanctions, card data, KYC
  myDomainPolicy,          // your own business rules
);

// compose() guarantees:
// - Rules evaluated in order across all component policies
// - First match wins within a single evaluation
// - defaultEffect is the STRICTEST across all composed policies
// - If any component is deny, composed policy is deny

One important constraint: avoid always() catch-all rules inside composable policies. If a component policy catches every call with always(), it prevents later policies' specific rules from ever firing. Use defaultEffect for fallthrough behaviour instead.

Built-in profiles

OWASP Agentic Top 10 (2026)

owaspTop10Policy provides coverage for all ten risks in the OWASP Top 10 for Agentic Applications:

ASI01 (Goal Hijack): Deny shell tools, prompt injection patterns, goal-modification language
ASI02 (Tool Misuse): Deny unapproved file writes and card PAN in input; escalate network calls
ASI03 (Identity Abuse): Escalate privileged tools invoked from subagents
ASI04 (Supply Chain): Escalate runtime package installs and dynamic tool registration
ASI05 (Code Execution): Deny eval()/exec() patterns; escalate code runner tools
ASI06 (Context Poisoning): Escalate memory writes; audit memory reads
ASI07 (Inter-Agent Comms): Escalate cross-agent and cross-session invocations
ASI08 (Cascading Failures): Escalate bulk operations exceeding 100 items
ASI09 (Trust Exploitation): Deny impersonation language; escalate approval-bypass patterns
ASI10 (Rogue Agents): Deny self-replication and self-deployment; escalate autonomous scheduling

Financial services baseline

financialBaselinePolicy covers jurisdiction-agnostic financial controls:

Deny self-transfers, negative amounts, sanctioned countries (OFAC/FATF list), card PANs, CVV in input
Escalate USD/NGN/KES CTR thresholds, international wire transfers, KYC bypass language, subagent financial writes
Audit customer PII access, moderate-value transactions, report generation
Allow explicit read-only tools (get_balance, get_exchange_rate, check_kyc_status)

The audit trail

Every deny, escalate, and audit decision writes a structured entry to your configured logger. The schema:

interface AuditEntry {
  id: string;           // UUID v4
  timestamp: string;    // ISO 8601
  toolName: string;
  effect: "deny" | "escalate" | "audit" | "allow";
  ruleName: string;     // which rule fired (or "default")
  policyName: string;
  reason: string;
  riskLevel: "critical" | "high" | "medium" | "low";
  owaspRisks: string[]; // e.g. ["ASI01", "ASI03"]
  sessionId?: string;
  principalId?: string;
  sanitizedInput: Record<string, unknown>; // secrets redacted automatically
  evaluationMs: number;
  outcome: "denied" | "escalated" | "executed" | "approved";
}

Automatic sanitization replaces keys matching password, token, api_key, cvv, secret, ssn, nin, pin with [REDACTED]. Strings over 500 characters are truncated. The audit log itself should never become a liability.

Four backends ship out of the box: ConsoleAuditLogger, FileAuditLogger, MultiAuditLogger, and InMemoryAuditLogger (for tests).

Testing without a live runtime

evaluatePolicy runs the policy evaluation synchronously without needing an Eve runtime. Combined with InMemoryAuditLogger, you can write comprehensive policy tests with standard unit test tooling.

import { evaluatePolicy } from "eve-policy";
import { InMemoryAuditLogger } from "eve-policy/audit";
import type { PolicyContext } from "eve-policy";

function ctx(toolName: string, input: Record<string, unknown> = {}): PolicyContext {
  return { toolName, toolInput: input, approvedTools: new Set() };
}

describe("transferPolicy", () => {
  it("escalates NGN transfers above ₦5M", () => {
    const decision = evaluatePolicy(
      transferPolicy,
      ctx("transfer_funds", { amount: 6_000_000, currency: "NGN" })
    );
    expect(decision.effect).toBe("escalate");
    expect(decision.owaspRisks).toContain("ASI02");
  });

  it("denies self-transfers", () => {
    const decision = evaluatePolicy(
      transferPolicy,
      ctx("transfer_funds", { source: "acc-001", destination: "acc-001", amount: 100 })
    );
    expect(decision.effect).toBe("deny");
  });

  it("allows read-only balance check", () => {
    const decision = evaluatePolicy(transferPolicy, ctx("get_balance"));
    expect(decision.effect).toBe("allow");
  });
});

No network calls. No Eve process. Fast and deterministic.

OWASP coverage reporting

uncoveredOwaspRisks() tells you which ASI risks your policy does not address. Use it as a CI gate:

import { uncoveredOwaspRisks, owaspCoverageReport } from "eve-policy";

const gaps = uncoveredOwaspRisks(myPolicy);
if (gaps.length > 0) {
  throw new Error(`Policy missing OWASP coverage: ${gaps.join(", ")}`);
}

This is the kind of thing that prevents "we have a governance layer" from drifting into "we have a governance layer with an unnoticed gap in ASI07."

What is coming next

The jurisdiction-specific policy packs — NDPA 2023, CBN AML/CFT, NFIU reporting, POPIA, Kenya DPA — are being developed as part of a separate package called @comply54/adapter-eve, which will provide pre-composed African regulatory profiles for direct use with eve-policy. That package is under active development and not yet released.

The underlying policy corpus (in OPA/Rego format) is already open source as agt-policies-nigeria, which was contributed upstream to microsoft/agent-governance-toolkit earlier this month. The @comply54/adapter-eve package will port those same frameworks into eve-policy's TypeScript rule format.

Discussion

Two questions I am genuinely curious about from people building with Eve or similar agent frameworks:

First — how are you currently handling governance for tools that need human approval? Are you implementing needsApproval directly in each tool, centralising it somewhere, or leaving it for later?

Second — the fail-closed default (defaultEffect: "deny") felt like the obvious choice to me, but I have seen arguments for fail-open defaults in development environments. What is your team's approach?

Drop your thoughts in the comments. And if eve-policy is useful, a star on the repo helps others find it.

I Found a Gap in Microsoft's AI Governance Toolkit. So I Built a Policy Pack to Fill It.

Oluwajuwon Omotayo — Sun, 14 Jun 2026 11:34:16 +0000

TL;DR

Microsoft's Agent Governance Toolkit (AGT) ships policy coverage for OWASP Agentic AI Top 10, NIST AI RMF, EU AI Act, SOC 2, and HIPAA — but nothing for African regulatory frameworks
I built agt-policies-nigeria, an open source community policy pack covering NDPA 2023 (Nigeria), CBN transaction limits, POS geo-fencing, BVN/NIN protection, NFIU AML/STR, and POPIA (South Africa)
Drop-in YAML policy files — no new infrastructure, no SDK changes, compatible with AGT's agent-os-kernel via GovernancePolicy + PolicyInterceptor
Includes a live demo: a Nigerian fintech support agent attempts 5 actions, the governance layer intercepts each one in real time
MIT licensed, contributions welcome — especially from anyone with direct CBN/NDPA/NFIU compliance experience

Repo: github.com/kingztech2019/agt-policies-nigeria

The gap

If you have looked at Microsoft's Agent Governance Toolkit, you know it is a solid piece of infrastructure for putting policy guardrails around what AI agents are allowed to do. Block certain outputs, require human approval for certain actions, audit every tool call. The policy coverage that ships with it maps onto some of the most important global frameworks: OWASP's Agentic AI Top 10, NIST's AI Risk Management Framework, the EU AI Act, SOC 2, HIPAA.

If you are building AI agents for a US healthcare company or a European fintech, AGT gives you policy packs that map directly onto your regulatory environment.

I went looking for the African equivalent. Specifically, I wanted to know: if I am building an AI agent for a Nigerian fintech — something that touches BVNs, NINs, CBN transaction limits, NDPA data residency rules — is there an AGT policy pack for that?

There is not. AGT covers five major global frameworks and zero African ones.

This is not a criticism of the AGT team. It is just a reflection of where the global AI governance conversation currently sits. Nobody contributing to AGT is thinking about NFIU suspicious transaction thresholds because that is not the regulatory environment most contributors operate in.

But AI agents are being deployed in Nigerian fintech, insurtech, and banking right now, making decisions that touch regulated financial data and sensitive personal identifiers. There was no governance tooling built for that context.

So I built a community policy pack to fill it.

What `agt-policies-nigeria` covers

Six policy packs, each mapping to a specific African regulatory framework, each shipped as a drop-in YAML file.

`ndpa-data-residency.yaml` — Nigeria Data Protection Act 2023

Blocks agent actions that route personal data outside Nigeria without adequate safeguards
Requires approval for bulk data export operations
Denies processing of sensitive personal data (health, biometric, ethnic origin) without conditions
Audits all PII-touching tool calls for NDPC accountability requirements

`cbn-transaction-limits.yaml` — Central Bank of Nigeria regulations

Tiered KYC limits: Tier 1 accounts capped at ₦50k daily, Tier 3 at ₦5M
Requires human approval for transfers approaching or exceeding NIP limits (₦10M)
Blocks autonomous agent self-approval of financial transactions — separation of duties enforced at the policy layer
USSD and contactless transaction ceiling enforcement

`pos-geofencing.yaml` — CBN Agent Banking Guidelines

Denies POS tool calls where terminal location context is absent or mismatched
Requires approval for POS registration changes and cross-state transactions
Audits all terminal activation and transaction events

`bvn-nin-protection.yaml` — NIBSS / NIN Regulations

Detects and blocks BVN/NIN patterns in agent output before logging or exposure
Denies passing BVN/NIN to external endpoints without approval
Requires human-in-the-loop for any BVN verification action
Masks identifiers in the audit trail itself

`nfiu-aml-str.yaml` — NFIU AML/CFT Regulations

Requires approval for transactions at or above the ₦5M CTR threshold
Detects structuring patterns (smurfing — multiple amounts just under a threshold)
Velocity controls flag unusual transaction frequency within a session
Blocks agents from autonomously completing transactions that should trigger an STR

`popia-south-africa.yaml` — Protection of Personal Information Act (South Africa)

Blocks cross-border transfers to non-POPIA-adequate jurisdictions
Denies processing of special personal information without lawful conditions
Detects SA ID numbers in agent output and blocks exposure
Audits all personal information processing for responsible party accountability

How it works with AGT

The policy files are plain YAML rule definitions. To use them, you load the relevant pack(s), extract the blocked patterns, and wire them into AGT's GovernancePolicy and PolicyInterceptor:

import yaml, re
from pathlib import Path
from agent_os.integrations import GovernancePolicy
from agent_os.integrations.base import PolicyInterceptor, ToolCallRequest

# Load regex patterns from any policy file(s)
def load_patterns(policy_files):
    patterns = []
    for path in policy_files:
        doc = yaml.safe_load(Path(path).read_text())
        for rule in doc.get("rules", []):
            cond = rule.get("condition", {})
            if cond.get("operator") == "matches" and cond.get("field") == "output":
                if rule.get("action") in ("deny", "block", "escalate"):
                    patterns.append(cond["value"])
    return patterns

patterns = load_patterns([
    "policies/cbn-transaction-limits.yaml",
    "policies/bvn-nin-protection.yaml",
])

policy = GovernancePolicy(
    name="nigerian-fintech",
    blocked_patterns=patterns,
    log_all_calls=True,
)

interceptor = PolicyInterceptor(policy)

That's it. No new infrastructure. The policy files are validated using AGT's own compliance linter, so you can confirm every pack is well-formed before deploying:

from agent_compliance.lint_policy import lint_file
from pathlib import Path

for p in sorted(Path('policies').glob('*.yaml')):
    r = lint_file(str(p))
    errors = [m for m in r.messages if m.severity == 'error']
    print(('✅' if not errors else '❌'), p.name)

The demo: 5 actions, 5 decisions

The repo includes an end-to-end demo at examples/nigerian-fintech-demo/. It simulates a Nigerian fintech support agent attempting five actions, with the governance layer intercepting each one live based on the loaded policy files:

Step	Action	Decision	Policy Pack
1	₦6.5M refund attempt	⏳ ESCALATED	`cbn-transaction-limits.yaml`
2	BVN exposed in response	❌ BLOCKED	`bvn-nin-protection.yaml`
3	Export records to AWS US-East-1	⏳ ESCALATED	`ndpa-data-residency.yaml`
4	KYC bypass + payment	⏳ ESCALATED	`nfiu-aml-str.yaml`
5	Normal customer lookup	✅ ALLOWED	—

Every decision is written to a timestamped audit log satisfying NDPA section 30 accountability requirements.

Run it yourself:

python3 -m venv .venv
.venv/bin/pip install agent-os-kernel agent-governance-toolkit-compliance
.venv/bin/python3 examples/nigerian-fintech-demo/demo.py

What I find most useful about this demo is that it makes "AI governance" concrete. It is easy to talk about governance in the abstract — policy documents, compliance frameworks, risk classifications. This demo shows what it actually looks like at the point of execution: an agent tries to do something, a policy intercepts it, a decision gets logged with a citation to the specific regulation that justifies it.

Why this matters beyond Nigeria

Nigeria is moving toward a risk-based AI regulatory framework. NITDA is expected to become the primary regulator for AI systems deployed in the country, with risk classification, mandatory audits for high-risk systems, and fines for non-compliance.

When that enforcement begins, companies running AI agents that touch financial data or personal identifiers will need to demonstrate that those agents operate within documented governance boundaries — with an audit trail.

Most companies will not be able to demonstrate that today. Not because they are negligent, but because the tooling to build that governance layer for the Nigerian regulatory context did not exist.

This pack is an attempt to close that gap before enforcement makes it urgent — and the same gap almost certainly exists for other African markets. The roadmap includes a Kenya Data Protection Act 2019 pack, ECOWAS cross-border transfer rules, SIM swap fraud detection patterns, NAICOM insurtech AI governance rules, and SEC Nigeria capital markets AI rules. None of those exist yet either.

Contributing

This project is intentionally incomplete, and the parts that matter most need input from people with real regulatory experience, not just engineering experience.

If you work in Nigerian fintech compliance, NDPA enforcement, or NFIU reporting and something in these policy packs is wrong, incomplete, or could be sharper — that is exactly the contribution this needs.

To propose a new rule:

Open an issue describing the regulation, the specific obligation, and the agent action pattern it should govern
Reference the exact regulatory citation (e.g. "NDPA 2023 s.25(1)(b)")
Submit a PR with the rule and a test case in examples/

See CONTRIBUTING.md for full guidelines.

There's also a planned ndpa-2023-mapping.md — a full NDPA → AGT control mapping intended as a contribution back to the AGT upstream repo, once this pack has real-world validation.

Discussion

A few questions for the community:

If you are building AI agents for regulated industries outside the US/EU — what regulatory frameworks are you working with, and is there existing tooling for them, or are you building governance layers from scratch?

And for anyone who has used AGT or similar agent governance toolkits — how are you currently handling region-specific compliance that the toolkit does not cover out of the box?

I'd also genuinely like to hear from anyone working in African fintech compliance. The roadmap for this project depends on practitioners pointing out what's missing or wrong.

Star the repo if this is useful: github.com/kingztech2019/agt-policies-nigeria

Your Project Board Looks Fine. So, Why Do You Keep Missing Deadlines? I Built Cadence to Find Out.

Oluwajuwon Omotayo — Sat, 13 Jun 2026 17:34:24 +0000

TL;DR

I built Cadence, an open source delivery analytics tool for Plane that surfaces cycle time, bottlenecks, team health, and Monte Carlo delivery forecasts
It connects read-only to any Plane workspace, syncs issue history, and computes the metrics that Plane's board view does not show you
This post walks through the Monte Carlo forecasting engine in detail — how it turns historical throughput into a probability distribution of delivery dates
Live demo: cadence-plane-analytics.netlify.app
Repo: github.com/kingztech2019/cadence-plane-analytics

The problem with project boards

Every team I have worked with uses some flavour of Kanban board. Plane, Jira, Linear, Trello — the shape is always the same. Columns for backlog, in progress, review, done. Cards move left to right. The board looks fine. Cards are moving. Sprints are closing.

And yet, deadlines keep slipping.

The board tells you the state of work right now. It does not tell you the things that actually determine whether you will hit your deadline:

How long does work actually take, from the moment someone picks it up to the moment it ships? Not the estimate — the real distribution, including the outliers.

Where does work get stuck? Not "QA is sometimes slow" — which stage, for how long, and is it getting worse?

Who on the team is quietly overloaded, and who has been stuck on the same ticket for three weeks?

Given everything we know about how this team has shipped over the last few months, what is the realistic range of dates for finishing what's left in this sprint?

Plane is a genuinely good open source project management tool. But like most PM tools, it shows you the board. It does not answer these questions. I built Cadence to answer them.

What Cadence does

Cadence connects to a Plane workspace — cloud or self-hosted — via API token or OAuth. It is strictly read-only; it never writes to your workspace, never modifies issues. It continuously syncs your issues and their full state-transition history into its own database, then computes a set of analytics that Plane's dashboards do not surface.

The metrics fall into three groups.

Delivery speed metrics — cycle time (with P50/P85 percentiles and scatter distribution), lead time (created to done, including wait time), flow efficiency (active time vs total time, benchmarked against the ~15% industry median), and sprint-over-sprint velocity comparisons.

Flow health metrics — a Cumulative Flow Diagram showing work-in-progress across stages over time, a bottleneck tracker that identifies which stage delays work most and escalates to "Critical" after three consecutive 30-day periods of being the bottleneck, scope creep tracking per sprint, and an At-Risk Radar showing in-progress issues that have already exceeded their stage's P85 duration.

Team and forecasting — per-person throughput and cycle time, team health flags for overloaded members and high reactivation rates, cross-project contributor views, and the Monte Carlo delivery forecast.

There is also a "Project Pulse" strip that appears on every page — a one-line signal surfacing the most important thing happening in a project right now, whether that's a new at-risk issue, a trend change, or a persistent bottleneck.

And an AI Sprint Retrospective feature, powered by OpenRouter, that generates a narrative comparing the current sprint to the prior one.

Deep dive: the Monte Carlo forecast

This is the feature I want to focus on, because I think it is the one most teams have never had access to, and it changes how you think about deadlines once you have it.

The problem with traditional estimates

Most teams forecast delivery dates by summing story point estimates and dividing by velocity. "We have 40 points left, we do 10 points per sprint, so 4 more sprints."

This produces a single number. A single number implies certainty. But software delivery is not certain — it is a distribution. Some tickets take half a day. Some take three weeks. The average hides the variance, and the variance is exactly the thing that determines whether your "4 sprints" estimate is realistic or wishful thinking.

What Monte Carlo simulation does instead

Instead of asking "what is our average throughput," Cadence asks a different question: "given everything we know about how this team has actually shipped work, what does a realistic range of outcomes look like?"

The approach is straightforward conceptually:

Take the team's actual historical throughput — how many issues were completed per week, for as much history as is available.
Run a simulation: starting from the current backlog size, repeatedly sample a random week's throughput from that history and subtract it from the remaining backlog, counting how many weeks it takes to reach zero.
Repeat this simulation 10,000 times.
Each of those 10,000 runs produces a "weeks to completion" number. Sort them.
The result is a distribution. The P50 (median) is the date by which there's a 50% chance you're done. The P85 is the date by which there's an 85% chance. The P95 gives you the conservative, "if things go badly" estimate.

This is fundamentally different from a single-point estimate. Instead of telling a stakeholder "we'll be done March 15," Cadence tells them "there's a 50% chance we're done by March 15, an 85% chance by March 22, and a 95% chance by March 29." That is a much more honest — and much more useful — thing to communicate.

Why sampling from real history matters

The key design decision is that the simulation samples from the team's actual historical weekly throughput, not from an assumed distribution like a normal curve.

Real team throughput is not normally distributed. It has good weeks and bad weeks — public holidays, a team member on leave, an unexpectedly gnarly bug that ate three days, a week where everything just clicked and the team shipped double the usual amount. A normal distribution would smooth all of that away. Sampling from real history preserves it.

This means the forecast naturally accounts for the team's actual rhythm, including its bad weeks, without anyone having to manually adjust for "but we have a public holiday next month" or "two people are on leave in March." If those patterns are reflected in the historical data — and over enough history, recurring patterns like holiday seasons tend to be — the simulation captures them implicitly.

Implementation shape

At a high level, the forecast computation in Cadence looks like this:

function monteCarloForecast(
  weeklyThroughput: number[],  // historical completions per week
  remainingBacklog: number,
  simulations = 10000
): { p50: number; p85: number; p95: number } {
  const results: number[] = [];

  for (let i = 0; i < simulations; i++) {
    let remaining = remainingBacklog;
    let weeks = 0;

    while (remaining > 0) {
      // Sample a random week from actual history
      const sampledThroughput =
        weeklyThroughput[Math.floor(Math.random() * weeklyThroughput.length)];

      remaining -= sampledThroughput;
      weeks++;

      // Safety cap to avoid infinite loops on zero-throughput history
      if (weeks > 520) break;
    }

    results.push(weeks);
  }

  results.sort((a, b) => a - b);

  return {
    p50: results[Math.floor(simulations * 0.50)],
    p85: results[Math.floor(simulations * 0.85)],
    p95: results[Math.floor(simulations * 0.95)],
  };
}

The actual implementation in Cadence does this as a PostgreSQL-backed computation over synced issue data — metricsService.ts builds the weekly throughput series from the issue state-transition history that the sync workers have already pulled in, then simulates that series.

A few practical details that mattered in getting this right:

Minimum history requirements. With very little history — say, two or three weeks — the simulation will technically run, but the result is close to meaningless. Cadence surfaces a warning when there isn't enough historical data for the forecast to be statistically useful, rather than presenting a confident-looking number built on noise.

Backlog definition. "Remaining backlog" needs a clear definition — is it all open issues in the project, or a filtered subset (a specific sprint, a specific label)? Cadence's forecast respects the same filter bar that every other metric page uses, so you can ask "given our current velocity, how long will it take to clear everything tagged v2-launch?"

Recomputation frequency. The forecast is recomputed as new sync data comes in, not on every page load. Running 10,000 simulations on every request would be wasteful given that the underlying data only changes when Plane issues change state — which the incremental sync picks up every 30 minutes, or in real time if webhooks are configured.

What this looks like in practice

On the Forecast page, you pick a target — typically "everything in the current sprint" or "everything in a specific milestone" — and Cadence shows you the P50/P85/P95 dates directly, along with the underlying throughput history the simulation drew from.

The practical effect: instead of a sprint planning conversation that ends with "we think we can get this done by Friday," you get a conversation that starts with "there's an 85% chance this is done by Friday, and a 50% chance it's done by Wednesday — do we want to scope down to hit the earlier date with more confidence, or are we comfortable with Friday as the realistic target?"

That is a fundamentally better conversation to have at the start of a sprint than at the end of it.

Architecture overview

For anyone interested in the broader system, Cadence is a Turborepo monorepo:

apps/web — Next.js 15 (App Router), Tailwind CSS v4, Recharts for all the visualisations
apps/api — Fastify 5 on Node.js 22, exposing the REST API and running the BullMQ workers
packages/shared — TypeScript types shared between frontend and backend

The sync pipeline uses a two-priority BullMQ queue backed by Redis. When you connect a workspace, a high-priority job backfills the last 90 days of issue history first — typically done in about 5 minutes — so you have usable charts quickly, while a low-priority job backfills the complete history in the background, which can take 30-60 minutes depending on workspace size. After the initial backfill, an incremental sync polls Plane every 30 minutes for changes, with optional real-time updates via Plane webhooks (HMAC-SHA256 verified).

All of this runs against PostgreSQL 16, leaning on PERCENTILE_CONT for the P50/P85 calculations and window functions for the time-series metrics like the CFD.

Security-wise: Plane API tokens are encrypted at rest with AES-256-GCM, webhook signatures are verified with constant-time comparison, and shareable dashboard links use 16-byte random hex tokens that cannot be enumerated.

Try it

The whole thing is open source under AGPL-3.0. There's a live demo at cadence-plane-analytics.netlify.app, or you can self-host with Docker Compose:

git clone https://github.com/kingztech2019/cadence-plane-analytics.git
cd cadence-plane-analytics
cp .env.example .env
# set POSTGRES_PASSWORD, JWT_SECRET, ENCRYPTION_KEY in .env
docker compose up -d

Then open localhost:3001, sign up, and connect your Plane workspace URL and API token from Connections.

Discussion

I am curious about two things from teams using Plane, Jira, Linear, or similar tools.

First — if you have used Monte Carlo forecasting before (or tools like it, such as Actionable Agile or Nave), how has it changed sprint planning conversations on your team? Did stakeholders push back on probabilistic estimates versus single-date estimates?

Second — what metric do you wish your PM tool surfaced that it currently does not? I have a roadmap (multi-workspace comparisons, SLA tracking, label/epic analytics) but I would rather build what teams actually need than what I assume they need.

Drop your thoughts below. And if Cadence looks useful, a star on the repo helps others find it.

I Built an Open Source Go SDK for Squad by GTCO. Here Is What I Learned About Payment API Design.

Oluwajuwon Omotayo — Thu, 11 Jun 2026 10:14:55 +0000

TL;DR

I built go-squad — a comprehensive, idiomatic Go SDK for the Squad by GTCO payment gateway
Zero external runtime dependencies, full test coverage, and a squadtest mock server for unit testing integrations without hitting real APIs
This post covers the design decisions behind the SDK and what building it taught me about payment API design in the Nigerian fintech context

go get github.com/kingztech2019/go-squad

Docs: pkg.go.dev/github.com/kingztech2019/go-squad
Repo: github.com/kingztech2019/go-squad

Why I built this

I have been building fintech products in Nigeria for a while. Squad by GTCO is one of the most capable payment gateways in the market — it handles transactions, virtual accounts, transfers, VAS, sub-merchant management, disputes, and webhooks. The API surface is genuinely broad.

But every time I integrated it into a Go project, I was writing the same boilerplate. HTTP clients. JSON marshalling. Pagination loops. Webhook signature validation. Error handling for the specific error shapes Squad returns. And every project had slightly different, slightly wrong implementations of the same things.

The most common bug I kept seeing — in my own code and in code I reviewed — was the kobo confusion.

The Squad API uses kobo as the base denomination for NGN amounts. ₦5,000 is 500000 in the API. If you pass 5000 instead, you charge the customer ₦50, and nobody notices until reconciliation. It is the kind of bug that slips through tests because the payment succeeds, just for the wrong amount.

I wanted a single, well-tested library that handled all of this correctly, consistently, and idiomatically in Go. So I built one.

What the SDK covers

client := squad.New(os.Getenv("SQUAD_SECRET_KEY"))

// Payments
resp, err := client.Transactions.InitiatePayment(ctx, &squad.InitiatePaymentParams{
    Email:       "customer@example.com",
    Amount:      squad.NGN(5000), // ₦5,000 — no kobo confusion
    Currency:    "NGN",
    CallbackURL: "https://yoursite.com/callback",
})

// Virtual accounts
account, err := client.VirtualAccounts.Create(ctx, &squad.CreateVirtualAccountParams{
    CustomerIdentifier: "cust-001",
    FirstName:          "Adaeze",
    LastName:           "Okafor",
    MobileNum:          "2348012345678",
    Email:              "adaeze@example.com",
    BVN:                "12345678901",
    DOB:                "01/01/1990",
})

// Transfers
transfer, err := client.Transfers.FundsTransfer(ctx, &squad.FundsTransferParams{
    TransactionRef: "pay-out-001",
    Amount:         squad.NGN(2000),
    BankCode:       "057",
    AccountNumber:  "0123456789",
    AccountName:    "John Doe",
    Currency:       "NGN",
})

// VAS — airtime, data, cable TV, electricity, SMS
_, err = client.VAS.BuyAirtime(ctx, &squad.BuyAirtimeParams{
    PhoneNumber:    "2348012345678",
    Amount:         squad.NGN(50),
    Network:        "MTN",
    TransactionRef: "air-001",
})

The full surface covers transactions, virtual accounts, transfers, sub-merchant management, disputes with evidence upload, all VAS operations, and webhooks.

Design decisions worth talking about

1. Money helpers that prevent the most common bug

squad.NGN(5000)       // → 500000 (₦5,000 in kobo)
squad.NGN(1)          // → 100    (₦1.00 in kobo)
squad.USD(50)         // → 5000   ($50.00 in cents)
squad.FromKobo(50000) // → 500.0  (display value)
squad.FromCents(5000) // → 50.0   (display value)

This is the first thing I added. Every amount field in the SDK is int64 (kobo), not float64 (naira). You cannot accidentally pass a naira amount — the type system pushes you toward the helpers. If you call squad.NGN(5000), you get 500000. There is no ambiguity.

This sounds obvious. But I have seen this bug in production codebases multiple times. The fix is architectural — make the wrong thing hard to write.

2. Auto-pagination iterator

Every listing endpoint in the Squad API is paginated. Most codebases I have seen implement the same manual loop:

// Without iterator — repetitive and error-prone
page := 1
for {
    result, _ := client.Transfers.GetAllTransactions(ctx, &squad.TransferListParams{Page: page, PerPage: 50})
    for _, t := range result.Transfers { process(t) }
    if len(result.Transfers) < 50 { break }
    page++
}

The SDK exposes an Iter type that fetches pages lazily:

// With iterator — clean, handles all edge cases automatically
iter := client.Transfers.All(ctx, &squad.TransferListParams{PerPage: 50})
for iter.Next() {
    process(iter.Item())
}
if err := iter.Err(); err != nil { log.Fatal(err) }

The iterator is generic — Iter[T] — so it works across all listing endpoints with full type safety. Page fetching happens lazily on each Next() call, so you only pay for the pages you actually consume.

This pattern is borrowed from the Stripe Go SDK, which I think is the gold standard for payment SDK design.

3. Idempotency keys to prevent duplicate charges

Network failures during payment requests are a real problem in Nigeria. If you retry a payment initiation request after a timeout, you risk charging the customer twice.

The SDK supports idempotency keys at the context level:

key, err := squad.GenerateIdempotencyKey()
// Store key in your DB alongside the order BEFORE calling Squad.
ctx = squad.WithIdempotencyKey(ctx, "order-"+orderID+"-"+key)
resp, err := client.Transactions.InitiatePayment(ctx, params)
// On network failure, retry with the SAME ctx — same key, no double charge.

Or you can opt into automatic key generation for all POST requests:

client := squad.New(key, squad.WithAutoIdempotency())

The important design decision here is that idempotency is attached to the context, not the params struct. This means you can inject it from your middleware layer without touching your business logic.

4. The webhook router

Webhook handling in most codebases is a giant switch statement on event type strings, with manual signature validation scattered across the handler. The SDK ships a typed webhook router:

router := squad.NewWebhookRouter(os.Getenv("SQUAD_SECRET_KEY")).
    OnTransactionSuccess(func(ctx context.Context, body *squad.WebhookTransactionBody) error {
        return fulfillOrder(body.TransactionRef, body.Amount)
    }).
    OnVirtualAccountCredit(func(ctx context.Context, body *squad.WebhookVirtualAccountBody) error {
        return creditCustomer(body.CustomerIdentifier, body.Amount)
    }).
    OnDisputeOpened(func(ctx context.Context, body *squad.WebhookDisputeBody) error {
        return notifyTeam(body.TicketID, body.Reason)
    }).
    OnError(func(w http.ResponseWriter, r *http.Request, err error) {
        log.Printf("webhook error: %v", err)
        http.Error(w, "error", http.StatusInternalServerError)
    })

http.Handle("/webhook/squad", router)

The router validates the HMAC-SHA512 signature, parses the body into the correct typed struct based on the event type, and dispatches to your handler. It implements http.Handler directly so you can register it with any standard Go HTTP framework.

Signature validation uses constant-time comparison to prevent timing attacks.

5. The `squadtest` mock server

This is the part I am most pleased with.

Testing payment integrations is painful. You either hit a real sandbox (slow, flaky, requires network) or you mock at the HTTP level (verbose, not type-safe). The squadtest package provides a full mock Squad API server:

func TestMyCheckoutService(t *testing.T) {
    srv := squadtest.NewServer(t) // starts a mock server, shuts down when test ends

    srv.OnInitiatePayment(func(p *squad.InitiatePaymentParams) (*squad.InitiatePaymentResponse, error) {
        if p.Amount != squad.NGN(5000) {
            t.Errorf("unexpected amount: %d", p.Amount)
        }
        return &squad.InitiatePaymentResponse{
            CheckoutURL:    "https://fake-checkout.squadco.com/abc",
            TransactionRef: p.TransactionRef,
        }, nil
    })

    // Inject srv.Client() into your service under test
    myService := checkout.NewService(srv.Client())

    url, err := myService.StartCheckout("customer@example.com", squad.NGN(5000))
    if err != nil { t.Fatal(err) }

    // Assert on what your code actually sent
    if srv.RequestCount() != 1 {
        t.Errorf("expected 1 request, got %d", srv.RequestCount())
    }
}

The mock server:

Starts and stops automatically with the test lifecycle via t.Cleanup
Returns typed responses that match the real API shape
Records all requests so you can assert on what your code sent
Supports custom handlers for any endpoint via srv.Handle(method, path, fn)

No real network calls. No sandbox credentials needed in CI. Fast and deterministic.

go get github.com/kingztech2019/go-squad/squadtest

What building this taught me

Nigerian payment APIs have genuinely different constraints from Western ones.

The kobo denomination issue is the obvious one. But there are subtler things. The NUBAN virtual account flow requires BVN, and building that into a type-safe API surface means thinking carefully about which fields are always required versus sometimes required. The VAS surface — airtime, data, cable TV, electricity — reflects a market where bills are paid through payment APIs rather than through bank direct debits. That changes the shape of the API significantly.

Zero external runtime dependencies is worth the effort.

The SDK has no runtime dependencies beyond the Go standard library. Every dependency you add is a dependency your users have to manage, audit, and update. For a payments library — where supply chain security matters — keeping the dependency surface minimal is not just aesthetics. It is a security posture.

The test infrastructure is part of the product.

The squadtest package is not a nice-to-have. It is one of the most important parts of the library. If developers cannot test their integration easily, they will not write tests. If they do not write tests, they will have production bugs. A payment SDK that makes testing hard is a payment SDK that ships broken integrations into production.

Using it in your project

go get github.com/kingztech2019/go-squad

Requires Go 1.21 or later.

Sandbox is auto-detected from your key prefix — if your key starts with sandbox_sk_, the SDK routes to the sandbox API automatically. No configuration needed.

import (
    "context"
    "os"

    squad "github.com/kingztech2019/go-squad"
)

client := squad.New(os.Getenv("SQUAD_SECRET_KEY"))

Full documentation on pkg.go.dev: pkg.go.dev/github.com/kingztech2019/go-squad

Contributing

Contributions are welcome. The areas I am most interested in help with:

More squadtest handler coverage for endpoints not yet mocked
Additional examples in the examples/ directory
Documentation improvements

See CONTRIBUTING.md for guidelines.

Discussion

A few questions I am genuinely curious about from the Go community:

If you have integrated payment gateways in Go before — what is the most common mistake you have seen in payment integration code? And is there a pattern in the SDK you would have designed differently?

Drop your thoughts in the comments. I read everything.

I Tried to Build a SaaS First. Here Is What It Cost Me.

Oluwajuwon Omotayo — Wed, 10 Jun 2026 17:17:31 +0000

TL;DR

Most developers jump straight to building a SaaS product before they have any distribution. The product fails not because it is bad, but because nobody knows it exists.
Services are not a consolation prize. They are the fastest way to validate your product idea, earn your first revenue, and build the market knowledge your product needs before you write a line of code.
The right sequencing is: service first, distribution second, product third. In that order.

Let me tell you something I have not said publicly before.

Before GinuxAI. Before BuySmart. Before any of the products I write about — I spent months building things nobody asked for.

Not because I was not skilled enough. I was.

Not because the ideas were bad. Some were genuinely good.

I built them before I had a single user. Before I had validated that anyone would pay. Before I had talked to enough people to understand whether the problem I was solving was painful enough to make someone open their wallet.

I went straight to the product.

And I paid for it in months, in opportunity cost, and in the quiet frustration of finishing something and realising I now had to start from zero on the harder problem: getting anyone to care.

This article is about what I learned. And what I wish someone had told me before I learned it the expensive way.

The SaaS dream and why it is a trap for most developers

There is a version of the SaaS story that gets told constantly in developer communities.

Build a product. Launch it. Get users. Generate monthly recurring revenue. Scale.

It sounds clean. It sounds like a system. It sounds like the logical extension of the engineering mindset we already have — define the problem, build the solution, deploy it.

But there is a step that version of the story leaves out entirely.

Distribution.

The developers you see online who have built successful SaaS products — the ones doing serious MRR, the ones with the Twitter threads about their revenue growth — almost all of them had something before the product.

An audience. A following. A network of people who already trusted them. A distribution channel they had been compounding for years before they had anything to sell.

When they launched, they were not launching into silence. They were pulling a lever that was already built.

Most developers do not have that lever. I did not have it.

And without distribution, even the best product shouts into a void.

Your product can be objectively better than the alternative. It can be faster, cheaper, and more thoughtfully designed. And it will still sit undiscovered because nobody knows you exist and you have no mechanism to change that.

The product was never the bottleneck.

Distribution was.

What I should have done first

The fastest path to a product that people actually want is through service.

Not consulting forever. Not replacing one job with another. But starting with service deliberately, as a strategy, before you write the first line of your product's code.

Every conversation you have with a paying service client is market research that no survey, no Reddit thread, and no validation framework can replicate.

You are inside their workflow. You are watching them use the broken tools they currently tolerate. You are hearing the exact words they use to describe their problem — which are almost never the words a developer would use to describe the same problem. You are seeing which part of the process makes them frustrated enough to pay someone to fix it.

That intelligence is worth more than months of building in isolation.

And here is the part that changes everything: they are paying you to gather it.

The client paying you for a service is, without knowing it, funding your research into the product you will eventually build. They are telling you the price point before you have to guess it. They are telling you the features that matter and the ones that do not. They are pre-validating your roadmap with every conversation.

When you eventually build the product, you are not guessing. You are building what you already know people will pay for because they have been paying for the manual version of it.

The identity shift nobody talks about

There is a deeper reason most developers never make the transition from employee to founder. And it is not the one they think it is.

It is not lack of skill. Developers are technically exceptional. That is not the gap.

It is not lack of ideas. Most developers have more ideas than they know what to do with.

The gap is identity.

For most of us, the mental model of what we are goes like this: I am a developer. I build things. I ship features. I solve technical problems. Someone else sells them.

That mental model is completely fine inside a job. It is lethal when you are trying to build something for yourself.

Because when you are building for yourself, you are not just the person who builds the thing. You are the person who identifies which thing to build, who decides what it costs, who explains why it is worth that, and who takes responsibility for whether it works.

Services force that shift.

The moment you sit across from a business owner, tell them their current process is costing them money, and propose a specific solution at a specific price — you are no longer an employee. You cannot be. Employees do not negotiate outcomes. Employees do not own the result.

That conversation changes you in a way that shipping another feature inside a product nobody uses never will.

The sequencing that actually works

Here is what this looks like in practice.

Start with people you already know. Not strangers. Not cold emails. The people in your phone, your family, your former colleagues. Think about which of them runs a business or works inside one.

Call them. Not to pitch. To ask one question: what is the most frustrating, time-consuming thing in your work right now?

Listen properly. Not to identify a technical solution immediately. To understand the shape of the pain.

When you hear something you know you can fix — offer to fix it. Charge for the outcome, not the hours. Deliver something that works. Document everything you learned.

Then find another client with a similar problem. And then another.

After three to five clients in the same space, you will start to see the pattern. The same friction. The same workflow. The same words to describe the same frustration. That pattern is your product.

Build for that pattern and you will know before you write the first line of code that someone will pay for what you are building. Because they already have.

Where I am now

GinuxAI is live. BuySmart is open source and growing.

Both are better products than they would have been if I had built them in isolation from the beginning. Because in the process of building publicly, writing about the market, and having conversations with real users, I have been doing exactly what services do — getting close to real people with real problems and letting that shape what I build.

But I would be lying if I said I got the sequencing perfectly right from the start.

The honest version is: I learned the sequencing by getting parts of it wrong. By building before validating. By discovering, after the fact, that some of the assumptions I built into early versions of the product were assumptions nobody had actually confirmed.

That is not a disaster. It is how almost everyone learns.

But you do not have to learn it the same way I did.

The sequencing is not complicated.

Solve a real problem for a real person. Get paid for it. Learn everything from that client. Repeat until you see the pattern. Then build the product that solves the pattern.

Services first. Distribution second. Product third.

In that order. Not because it is the comfortable path. Because it is the one that actually works.

Discussion

I am curious where you are in this journey.

Are you currently in build mode — working on a product before you have paying users? Or have you gone through the service-first path and built something from validated demand?

Drop your experience in the comments. Especially if you tried to skip straight to SaaS and paid for it the same way I did. I want to know what the pattern looks like for developers in different markets and contexts.

I write about building products in Africa, what the best builders on the continent are doing differently, and what I am learning as a founder. Follow me here on Dev.to or subscribe to my Substack at oluwajuwonomotayo.substack.com for the full archive.

DEV Community: Oluwajuwon Omotayo

[Boost]

I Spent Months Building the AI Governance Layer Africa Was Missing. Today It Launches.

I Spent Months Building the AI Governance Layer Africa Was Missing. Today It Launches.

TL;DR

The problem I kept running into

What comply54 does

Framework integrations

What is covered: 21 policy packs, 12 jurisdictions

Why 100% offline matters

The audit trail

What comes from the earlier work

What is next

Discussion

I Built a Policy Enforcement Layer for Vercel's Eve Agent Framework. Here's What I Learned About AI Governance the Hard Way.

TL;DR

Why Eve needs a governance layer

The design challenge: Eve's two-phase lifecycle

Installation and quick start

The four effects

Composing policies

Built-in profiles

OWASP Agentic Top 10 (2026)

Financial services baseline

The audit trail

Testing without a live runtime

OWASP coverage reporting

What is coming next

Discussion

I Found a Gap in Microsoft's AI Governance Toolkit. So I Built a Policy Pack to Fill It.

TL;DR

The gap

What agt-policies-nigeria covers

ndpa-data-residency.yaml — Nigeria Data Protection Act 2023

cbn-transaction-limits.yaml — Central Bank of Nigeria regulations

pos-geofencing.yaml — CBN Agent Banking Guidelines

bvn-nin-protection.yaml — NIBSS / NIN Regulations

nfiu-aml-str.yaml — NFIU AML/CFT Regulations

popia-south-africa.yaml — Protection of Personal Information Act (South Africa)

How it works with AGT

The demo: 5 actions, 5 decisions

Why this matters beyond Nigeria

Contributing

Discussion

Your Project Board Looks Fine. So, Why Do You Keep Missing Deadlines? I Built Cadence to Find Out.

TL;DR

The problem with project boards

What Cadence does

Deep dive: the Monte Carlo forecast

The problem with traditional estimates

What Monte Carlo simulation does instead

Why sampling from real history matters

Implementation shape

What this looks like in practice

Architecture overview

Try it

Discussion

I Built an Open Source Go SDK for Squad by GTCO. Here Is What I Learned About Payment API Design.

TL;DR

Why I built this

What the SDK covers

Design decisions worth talking about

1. Money helpers that prevent the most common bug

2. Auto-pagination iterator

3. Idempotency keys to prevent duplicate charges

4. The webhook router

5. The squadtest mock server

What building this taught me

Using it in your project

Contributing

Discussion

I Tried to Build a SaaS First. Here Is What It Cost Me.

TL;DR

The SaaS dream and why it is a trap for most developers

What I should have done first

The identity shift nobody talks about

The sequencing that actually works

Where I am now

Discussion

What `agt-policies-nigeria` covers

`ndpa-data-residency.yaml` — Nigeria Data Protection Act 2023

`cbn-transaction-limits.yaml` — Central Bank of Nigeria regulations

`pos-geofencing.yaml` — CBN Agent Banking Guidelines

`bvn-nin-protection.yaml` — NIBSS / NIN Regulations

`nfiu-aml-str.yaml` — NFIU AML/CFT Regulations

`popia-south-africa.yaml` — Protection of Personal Information Act (South Africa)

5. The `squadtest` mock server