DEV Community: Jamal Ibrahim Umar

The Smallholder Stack: Why a Nigerian Poultry + Catfish Farm Was the Right First Customer for an AI Operations SaaS

Jamal Ibrahim Umar — Sun, 28 Jun 2026 00:05:25 +0000

Part of the H0: Hack the Zero Stack submission. See the project on Devpost.

Nigeria is the launch market. It is not the ceiling.

This article explains the reasoning behind that distinction, and why the architecture I built for FarmOps Desk generalizes across the smallholder livestock economies of Sub-Saharan Africa, Southeast Asia, South Asia, and Latin America. The product decisions Nigeria drove are durable; the marketing decisions are not.

The problem is not Nigerian

The UN Food and Agriculture Organization estimates that smallholder farmers produce up to 80% of the food supply in developing countries and depend on livestock for a meaningful share of their income. The World Bank's IFC puts the smallholder agritech market at $510 billion annual spend across the regions where smallholders are the dominant producer.

The operational problems are uniform across these regions:

Mortality events. A poultry house loses 2-5% per cycle to heat stress, disease, or predation. In Nigeria, dry-season heat waves kill ~3% of broilers annually. In Bangladesh, summer humidity kills ~4%. In Indonesia, avian influenza takes 2-6%.
Feed management. Feed is 60-70% of variable cost. Mismanagement (wrong feed at the wrong phase, expired stock, underfeeding) erodes margin faster than any other variable. The arithmetic is identical in Lagos, Jakarta, and Nairobi.
Water quality for aquaculture. Dissolved oxygen crashes at dawn kill catfish ponds. The dynamic is the same in tarpaulin ponds in Kaduna and earthen ponds in Mekong Delta.
Financial discipline. Farmers mix personal and business cash. Money as integer kobo is the same pattern in NGN, IDR, PKR, BDT, or BRL.
Records for veterinary compliance. A broiler batch without a vaccination log can't be sold to a regulated processor. The compliance check is identical across exporting markets.

These are not "Nigerian problems." They are smallholder livestock problems, expressed in different currencies and languages across a $1.4 trillion addressable market (IFAD 2024 estimate, livestock sub-sector).

Why Nigeria first

Three reasons, none of which are sentimental:

1. Density. Nigeria is the 4th-largest poultry producer in the world by headcount (after China, Brazil, USA). It's also the fastest-growing catfish producer in Sub-Saharan Africa. The addressable farm count is in the millions.

2. Proven Payment Infrastructure. To build a B2B SaaS, you need reliable ways to process payments locally. Nigeria has robust payment providers like Nomba, which offer modern APIs (like webhooks and idempotency) similar to what Stripe uses globally. Because I built the payment layer to support Nomba's standard webhook pattern, integrating future local payment rails (like M-Pesa in Kenya or Pix in Brazil) will just require dropping in a new provider file, not rewriting the billing engine.

3. English-language reduces go-to-market friction. The AI's grounding prompts, the UI copy, and the demo video are all in English. For a solo dev or small team, this is significant. I can ship a Kenyan or Ghanaian version next month without re-recording or re-translating. (For non-English markets like Indonesia and Brazil, the farms.language column already supports per-farm localization; the system prompt adapts.)

Nigeria is a market of 200M people with a real poultry + catfish sector, real payment infrastructure, and English-language operation. Picking it first is a business decision, not a sentimental one.

The product decisions Nigeria drove (and why they generalize)

Every Nigeria-driven decision turned out to be a global-smallholder decision in disguise. This is the architecture's strongest claim to scalability.

Money as integer kobo

NGN has 100 kobo per naira. I store all monetary values as BIGINT kobo. The CHECK constraints (amount_minor >= 0, balance_after >= 0) work in any currency — IDR rupiah (no minor unit, just store rupiah as the minor), BDT paisa, PKR paisa, BRL centavos. The pattern is "smallest integer unit" — a Nigerian decision that generalizes to every currency on the planet.

The alternative — NUMERIC(10,2) float money — is the wrong answer everywhere, but most pronounced in markets with high inflation where small units matter.

Voice-first AI

Nigerian smallholder farmers are not all low-literacy, but the operational reality is: you're standing in a broiler house at 5am with two hands full of feed, and you don't have time to type. Voice is the natural interface.

The same is true in rural Indonesia, Bangladesh, Kenya, Brazil. The use-voice-session.ts component, the Bedrock Nova Sonic bidirectional session, the audio fallback via MediaRecorder — all of this generalizes. The system prompt language adapts from farms.language.

Per-farm autonomy tiers

A 200-bird subsistence farm in Kaduna has different risk tolerance than a 50,000-bird commercial operation in Lagos. The autonomy tier (suggest | draft | auto) lets each farm dial in. The same dial serves a 50-bird farm in Java and a 5,000-fish pond in Vietnam.

The crucial sub-decision — financial and destructive writes hardcoded to draft regardless of tier — is universal. No farmer anywhere wants the AI to record a sale or a mortality event without confirmation. The autonomy floor is a safety invariant, not a cultural preference.

Pluggable payment rail

lib/payments.ts has a provider interface with a mock implementation and a nomba implementation. Adding Stripe (for international cards), M-Pesa (Kenya), Pix (Brazil), or GoPay (Indonesia) is one provider file each. The webhook + idempotency pattern is identical across all of them; the diff is the request/response shape.

Pluggable messaging

lib/messaging/provider.ts abstracts Termii (Nigeria SMS) vs Resend (email). For Kenya, Africa's Talking slots in. For Indonesia, WhatsApp Business API. For Brazil, Twilio. The interface is the same.

Multi-currency, multi-language, multi-timezone

The schema has farms.currency, farms.language, farms.timezone. Today these are mostly set to NGN/en/Africa/Lagos in production. But the assistant system prompt is built per-request from farms.language. The daily insight schedule uses farms.timezone. The money formatter reads farms.currency. A farm in Bangladesh or Brazil works today, with no code change.

Generic species model

production_units.species is a TEXT column, not an enum. Today the UI surfaces broiler and catfish. The schema accepts goat, cattle, pig, duck, tilapia without modification — only the species catalog and the breed lists need updating. Nigeria's narrow focus is a UI choice, not a schema constraint.

A Scalable Expansion Model

Because the core architecture is decoupled from regional specifics, expanding to new markets becomes a data-entry exercise rather than a software rewrite. Here is how that scales:

Year	Market	TAM	What changes from the previous market
2026	Nigeria	$8B poultry + catfish	Launch market. Nomba payment, English UI.
2027	Kenya, Ghana	$5B poultry	Add M-Pesa payment rail. Same language. Same species.
2027	Indonesia, Philippines	$25B poultry + fish	Add GoPay / GCash payment. Bahasa Indonesia / Tagalog language pack. Same species.
2028	Brazil, India	$40B poultry + fish	Add Pix / UPI payment. Portuguese / Hindi language pack. Same species.
2029+	Vietnam, Bangladesh, Egypt	$30B+	Same pattern.

The key takeaway here is that entering a new market requires just four predictable updates: the currency, the payment provider, the language pack, and the local species/breed list. None of these require database schema changes. The cost of entering a new market is simply data onboarding and a single payment integration, not a platform rewrite.

The human stakes

The reason this matters more than the architecture is what the architecture is for.

Nigeria's poultry sector loses an estimated 15-20% of broiler production to preventable causes — heat stress, vaccination gaps, feed mismanagement. That's roughly ₦600 billion ($750M) per year in dead birds. A 5% reduction across the sector would be $375M/yr in farm income preserved.

The numbers scale across the regions: a 5% mortality reduction across Indonesia's poultry sector is another $500M/yr. Across Brazil's, $400M/yr. The aggregate smallholder livestock TAM for AI-assisted operations is in the tens of billions per year in recovered production, before counting the productivity gains.

This is the real-world impact that justifies the engineering effort. The architecture I described in the companion pieces — Aurora + pgvector + Bedrock, keyless OIDC, atomic credit reservation — is just the substrate. The reason to build it is the smallholder farmer who stops losing birds to a 4am heat wave because the assistant drafted a ventilation task the night before and the farmer confirmed it with one tap.

The Current State and What's Next

Core Features Implemented:

40+ table multi-tenant Aurora schema, money stored as integer kobo, and an append-only credit ledger
AI assistant with per-farm autonomy tiers, draft-confirmation flows, and a voice mode
Atomic credit reservation (preventing race conditions under concurrent load)
pgvector-powered RAG scoped securely per-farm
Keyless Vercel → Aurora → Bedrock trust chain (zero static credentials)
Real-world Nomba payment integration with webhook idempotency
1,629+ tests ensuring type-safety, linting, and build stability

Future Roadmap:

RDS Proxy for connection pooling (see my "Keyless by Default" article)
Integration with M-Pesa for the Kenyan market
Bahasa Indonesia language pack + GoPay integration
A vaccination scheduler with national-schedule presets
An offline-tolerant PWA for areas with poor connectivity
A vet marketplace for in-app consult booking

The global takeaway

The schema doesn't know it's about Nigeria. The currency column says NGN today and would say IDR or BRL or BDT tomorrow. The species column accepts any string. The payment interface accepts any provider. The language column drives the assistant's system prompt. The autonomy tier respects every culture's risk tolerance by giving each farm the dial.

The product launched in Nigeria because that's where the densest cluster of smallholder poultry + catfish farmers with real payment rails and English fluency happens to be. The architecture launched for the world.

Links

Code: Source code provided as a ZIP file download on the Devpost submission page.
Companion articles: Keyless by Default · AI Governance as a Database Primitive

Built for the H0 Hack the Zero Stack hackathon (#H0Hackathon), Monetizable B2B App track. Deployed on Vercel, Amazon Aurora PostgreSQL as primary backend, Amazon Bedrock for AI. Nigeria is the launch market, not the ceiling. I created this piece of content for the purposes of entering the hackathon.

Keyless by Default: Securing FarmOps Desk without a Single Static Secret

Jamal Ibrahim Umar — Sat, 27 Jun 2026 23:50:01 +0000

Part of the H0: Hack the Zero Stack submission. See the project on Devpost.

Every hackathon submission that uses AWS from Vercel usually starts the same way: "paste your AWS_ACCESS_KEY_ID into Vercel's environment variables." It's easy, and it works. It's also the single most common cause of cloud supply-chain attacks.

Major breaches like SolarWinds or the Toyota customer leak often start with a static credential that someone forgot to rotate, or accidentally checked into a code repository.

For the H0 hackathon, I built FarmOps Desk on Vercel + Aurora PostgreSQL + Bedrock. My goal was strict security: Zero static AWS credentials anywhere in the project, deployment, or CI pipeline.

Here is how I made the entire application "keyless."

The "Keycard" Approach (OIDC)

Instead of giving Vercel a permanent "master key" (a static AWS credential), I set up a system where Vercel requests a temporary, 15-minute "keycard" every time a function runs.

This is powered by Vercel's OIDC (OpenID Connect) integration with AWS:

When a Vercel function wakes up, Vercel gives it a cryptographically signed identity token.
The function hands this token to AWS.
AWS verifies the token, checks that it came from my specific Vercel project, and hands back a temporary session that expires in 15 minutes.

If a malicious actor somehow compromises the Vercel environment, they don't get a permanent key. They get a temporary session that evaporates almost immediately.

The Two-Role Split: Minimizing Blast Radius

A common mistake is creating a single AWS Role that has permissions to do everything (access the database, call the AI, read storage). That creates a massive blast radius. If the AI service is compromised, the database goes with it.

I split the permissions into two strictly isolated roles:

1. The Database Role (AWS_ROLE_ARN)

Only has permission to connect to the Aurora PostgreSQL database.
Has a strict "Permission Boundary" ensuring it can never be used to access Bedrock or S3.

2. The AI Role (BEDROCK_ROLE_ARN)

Only has permission to invoke the Bedrock Nova models.
Has zero access to read or write to the database.

By doing this, a bug or breach in the AI code path can be shut down entirely without affecting the database, and vice versa.

The Code: Simpler Than You'd Think

Thanks to modern SDKs, going keyless doesn't require thousands of lines of boilerplate.

For the database, I use the @aws-sdk/rds-signer to fetch a fresh token dynamically every time a new database connection is made. No passwords are ever stored on disk:

// lib/db.ts
const pool = new Pool({
  host: process.env.PGHOST,
  user: process.env.PGUSER,
  // Fetch a fresh 15-minute token dynamically instead of using a static password
  password: () => signer.getAuthToken(), 
  ssl: true,
});

For the Bedrock AI models, Vercel provides a helper that automatically trades the OIDC token for temporary AWS credentials:

// lib/ai/bedrock.ts
import { awsCredentialsProvider } from '@vercel/functions/oidc';

export function getBedrockRuntime() {
  return new BedrockRuntimeClient({
    region: 'us-east-1',
    credentials: awsCredentialsProvider({
      roleArn: process.env.BEDROCK_ROLE_ARN!,
    }),
  });
}

Handling Voice AI with Nova Sonic

A unique challenge of building an agricultural AI is that farmers' hands are often dirty or busy. The assistant needs a voice mode. I used Amazon Bedrock Nova Sonic for real-time, bidirectional voice streaming.

However, serverless environments like Vercel usually struggle with long-lived bidirectional streams. By default, the underlying HTTP/2 session drops after the first voice turn.

To solve this, I deployed a dedicated "Sonic Bridge" service to a long-running Amazon EC2 instance. The bridge uses a custom NodeHttp2Handler that extends the session timeouts to 5 minutes, letting the farmer keep an open conversation with the AI while walking through the poultry house.

The Keyless Deployment to EC2:
Usually, deploying to EC2 from GitHub Actions means storing an SSH private key or an AWS_ACCESS_KEY_ID in your GitHub repository secrets. That is exactly what I wanted to avoid.

Instead, I set up a fully keyless CI/CD pipeline for the bridge:

GitHub Actions uses its built-in OIDC provider to prove its identity to AWS.
AWS grants GitHub a short-lived session, assuming a strictly scoped IAM role.
The GitHub runner uses AWS Systems Manager (SSM) to securely send the deployment tarball and execute the bash rollout script directly on the EC2 instance.

Zero SSH keys. Zero static AWS credentials in GitHub. If the GitHub repository is ever compromised, there is no permanent key for an attacker to steal—just an OIDC trust policy that only works when triggered by a push to the main branch.

Scaling the Database (Next Steps)

Note: While not strictly required for hackathon traffic, production Vercel functions can easily exhaust Aurora's connection limits due to serverless concurrency.

To prevent the database from crashing under load, the production architecture places AWS RDS Proxy in front of Aurora. RDS Proxy acts like a traffic cop, multiplexing hundreds of Vercel connections down to a safe handful for Aurora. (I've included a comprehensive guide on my proxy setup in the project repository).

Why keyless architecture matters

Keyless authentication is a deliberate engineering decision. It is inherently harder to set up initially than pasting environment variables, but it is the production-grade answer for cloud security.

Shippable software is software that doesn't leak credentials. By eliminating static keys entirely, FarmOps can accept real customer data on day one without needing a "we'll rotate the keys before launch" excuse.

Links

Code: Source code provided as a ZIP file download on the Devpost submission page.
Live: deployed on Vercel (https://v0-farmops.vercel.app)
Companion articles: AI Governance as a Database Primitive · The Smallholder Stack (TAM & Scaling)
Vercel OIDC docs: vercel.com/docs/deployments/troubleshooting/oidc
RDS IAM auth: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth

Built for the H0 Hack the Zero Stack hackathon (#H0Hackathon). Deployed on Vercel, Amazon Aurora PostgreSQL as primary backend, Amazon Bedrock for AI. Zero static AWS credentials in the project. I created this piece of content for the purposes of entering the hackathon.

AI Governance as a Database Primitive: Building FarmOps Desk on Aurora + pgvector + Bedrock

Jamal Ibrahim Umar — Sat, 27 Jun 2026 23:03:07 +0000

This article is part of my submission to the H0: Hack the Zero Stack hackathon, in the Monetizable B2B App track.

Most "AI apps" treat the model as a stateless add-on: a chat UI tacked onto a CRUD app, calls billed to an API key the developer hopes nobody finds. The database stores the chat history; everything interesting happens outside it.

For a B2B SaaS where the AI writes financial records, drafts livestock medical notes, and creates operational tasks on behalf of paying customers, that approach fails. You need governance: who asked the AI, what tool it called, what it tried to write, what it actually wrote, how many credits it consumed, who approved the draft, who rejected it, why. All of this must be auditable weeks later, scoped per-tenant, and enforceable at the database level — not at the API layer hoping the model never hallucinates a missing tenant ID.

This article walks through the governance schema I built into FarmOps Desk for the H0 hackathon, and the two patterns that make it work: atomic credit reservation and per-farm autonomy tiers.

The thesis

Treat AI governance as a database primitive, not a feature. The schema enforces the invariants; the application is a thin layer over them. If the application has a bug, the database still prevents the unacceptable outcomes (a customer going into negative credits, a draft pretending to be confirmed, a tenant-A operation touching tenant-B data).

That means every interesting AI action lives in a small set of tables:

Table	Purpose
`ai_runs`	One row per model invocation. Feature, model, tokens, latency, status, summaries. The index of "what did the AI do".
`credit_ledger`	Append-only ledger of credit grants/deductions. The financial truth. `balance_after >= 0` enforced by CHECK.
`assistant_drafts`	Pending AI writes — every record the assistant wants to create lands here first. record_type + status state machine (`pending → confirmed / discarded`).
`ai_recommendations`	Non-mutating AI suggestions (no draft). Status `pending → approved / rejected`.
`ai_evals`	Rule-based code evals of assistant outputs (clinical safety filter, schema conformance).
`ai_feedback`	Thumbs up/down + free text. Joined back to `ai_runs` for offline analysis.
`memories`	Durable farm facts (e.g. "vaccinates on Mondays", "Pond 3 is the nursery") distilled from chat.
`embeddings`	pgvector. Per-farm RAG index for documents, conversation summaries, memories.

The relational spine: farms.id is the tenant boundary. Every row in every table above carries farm_id. Every query filters by it. A hallucination that tries to write to another farm can't — the row-level check is the schema, not a function the LLM can forget to call.

Pattern 1 — Atomic credit reservation

The classic serverless AI bug: two concurrent requests for the same farm both observe credit_balance = 1, both proceed, both invoke Bedrock, both call the settleCredits function afterward. The user gets charged for 2 runs on a 1-credit balance. This is a TOCTOU race that scales linearly with concurrency.

The naive fix is SELECT ... FOR UPDATE inside a transaction. That works but it doesn't compose with the metering pattern: you want to reserve 1 credit before the run (so the user can't start 10 concurrent runs on a 5-credit balance), then settle after the run with the actual cost.

My pattern:

-- reserveCredit(farmId): atomically deduct 1 IF balance > 0
UPDATE farms
   SET credit_balance = credit_balance - 1
 WHERE id = $1
   AND credit_balance > 0
RETURNING credit_balance;

This is a single conditional UPDATE. Postgres serializes concurrent calls at the row level. Exactly one of N concurrent calls returns a row when balance = 1; the rest get rowCount = 0 and throw CreditError. No advisory lock, no transaction, no two-phase protocol.

After the run completes:

// settleCredits(farmId, actualCredits, reason, aiRunId)
//   actualCredits <= 0  → refund the reservation
//   actualCredits === 1 → no-op (reservation was exact)
//   actualCredits > 1   → deduct the extra, best-effort

The credit_ledger table captures both legs (reservation + settle) so the audit trail reconstructs the actual cost of any run. A judge looking at /admin/evidence can match a credit_ledger row to its ai_runs row and see: 1 reserved, 3 actual, 2 deducted at settle.

This pattern generalizes to any metered-resource problem (storage quotas, rate limits, seat counts) where you need "reserve N if available, settle later" semantics.

Pattern 2 — Per-farm autonomy tiers

A small backyard poultry farm in Kaduna has different risk tolerance than a 5,000-bird commercial operation in Lagos. Some farms want the AI to suggest; others want it to act. The autonomy tier is a per-farm setting in farms.ai_autonomy:

Tier	Behavior
`suggest`	AI cannot write anything. Tools throw if called. User gets text suggestions only.
`draft`	AI creates `assistant_drafts` rows. User confirms or discards. Default for new farms.
`auto`	AI writes directly for trusted categories (tasks, notes, feed logs). Still drafts financial/destructive writes.

The crucial design choice: financial and destructive writes are hardcoded to draft, regardless of autonomy tier. No farm can opt out of human confirmation for a sale, expense, mortality event, or recommendation approval. The autonomy tier only controls the no-op write categories.

Implementation: farms.ai_autonomy is the tier; farms.ai_auto_categories is a JSONB allowlist for the auto tier; farms.ai_record_autonomy is per-record-type override. The lib/ai/draft-executor.ts resolves all three before each write. The schema is the source of truth; the executor is a small dispatcher.

// Pseudo
function resolveAutonomy(farm, recordType) {
  if (FINANCIAL_DESTRUCTIVE.has(recordType)) return 'draft'  // hardcoded floor
  if (farm.ai_autonomy === 'suggest') return 'suggest'
  if (farm.ai_autonomy === 'auto' && farm.ai_auto_categories.includes(recordType)) return 'auto'
  return 'draft'
}

This is the AI-safety pattern that doesn't depend on prompt engineering. The model can be convinced to do anything; the executor refuses the write at the schema level.

Why pgvector inside Aurora

RAG in a multi-tenant B2B has a specific shape: every vector query is scoped by farm_id, the corpus is per-tenant (documents, conversation summaries, memories), and the index must be transactional with the writes (a deleted document must not appear in search results).

Standalone vector databases (Pinecone, Weaviate) solve the vector problem but create a second source of truth: the vector DB says "doc X is relevant", you have to round-trip to Postgres to authorize the read, and the two can drift. You also pay for a separate service.

pgvector inside Aurora collapses the two into one. The vector column lives on the same row as the tenant ID:

CREATE TABLE embeddings (
  id          TEXT PRIMARY KEY,
  farm_id     TEXT NOT NULL,
  source_type TEXT NOT NULL,         -- 'memory' | 'document' | 'convo_summary'
  source_id   TEXT NOT NULL,
  content     TEXT NOT NULL,
  embedding   VECTOR(1024) NOT NULL
);

CREATE INDEX ON embeddings
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- Per-farm RAG query: tenant scoping + vector search in one shot
SELECT id, content, 1 - (embedding <=> $1) AS score
  FROM embeddings
 WHERE farm_id = $2                -- tenant boundary
   OR farm_id = '__global__'       -- shared knowledge base (vaccination schedules, biology)
 ORDER BY embedding <=> $1
 LIMIT 4;

The farm_id filter runs first; the HNSW scan runs against the filtered subset. A hallucinated query for tenant-A can't reach tenant-B's embeddings — the WHERE clause is enforced by Postgres, not by prompt engineering.

Why Aurora PostgreSQL (not DynamoDB)

The hackathon's first hard requirement is AWS Database as the primary backend. I chose Aurora PostgreSQL over DynamoDB for one reason: financial-grade operations require relational integrity.

My credit_ledger enforces balance_after >= 0 with a CHECK constraint. My assistant_drafts enforces record_type IN ('mortality','feed_use','sale','expense','water','weight','symptom','note') with a CHECK — the AI cannot draft a record type that doesn't exist. My farm_members enforces the join table invariant (farm_id, user_id) UNIQUE. None of these are expressible in DynamoDB without application-level enforcement.

The trade-off: Aurora is a heavier operational lift than DynamoDB (connection pooling, failover tuning, vacuuming). For a hackathon, I accepted the complexity because the integrity invariants are the product.

The architecture

┌──────────────┐    OIDC JWT    ┌──────────────┐
│   Vercel     │ ─────────────► │     STS      │
│  Functions   │                │ (AssumeRole) │
└──────┬───────┘                └──────┬───────┘
       │                                │
       │  15-min IAM token              │
       ▼                                ▼
┌──────────────┐                ┌──────────────┐
│ RDS Signer   │                │  Bedrock     │
│ (DB auth)    │                │  Runtime     │
└──────┬───────┘                └──────────────┘
       │
       ▼
┌──────────────────────────────────────────────┐
│       Aurora PostgreSQL 17 + pgvector        │
│  ┌────────────┐  ┌────────────┐  ┌─────────┐ │
│  │   farms    │  │ ai_runs    │  │ memories│ │
│  │   ...40+   │  │ credit_    │  │ embed-  │ │
│  │  tables    │  │ ledger     │  │ dings   │ │
│  │            │  │ drafts     │  │         │ │
│  └────────────┘  └────────────┘  └─────────┘ │
└──────────────────────────────────────────────┘

Two IAM roles: AWS_ROLE_ARN (DB-only, permission-boundary-capped) and BEDROCK_ROLE_ARN (AI-only, no DB access). Blast-radius minimization at the trust boundary.

Why this architecture matters

Building AI governance as a database primitive isn't the typical approach. Most LLM applications default to a simple messages table and a chat UI, treating the AI as an external novelty. But when building for agricultural operations, a farmer's data integrity is just as critical as a bank's.

By enforcing invariants natively in the relational schema—using integer kobo for financial accuracy, FOR UPDATE row locks to prevent race conditions, append-only ledgers, and a per-farm autonomy state machine—the application guarantees safety before the AI ever generates a response.

The patterns described here are designed to go beyond a proof-of-concept. They demonstrate how to build shipping-grade, multi-tenant AI systems where data integrity is structurally guaranteed by the database itself.

Links

Code: Source code provided as a ZIP file download on the Devpost submission page.
Live: deployed on Vercel (https://v0-farmops.vercel.app)
Companion articles: Keyless by Default · The Smallholder Stack (TAM & Scaling)

This project is built for the H0 Hack the Zero Stack hackathon (#H0Hackathon), in the Monetizable B2B App track. It deploys on Vercel with Amazon Aurora PostgreSQL as the primary backend. I created this piece of content for the purposes of entering the hackathon.