FINTECH// case study

Nexural — Full-Stack Fintech Platform

A trading platform built like an institution. Run by one person.

A production-grade trading platform with real-time execution, portfolio tracking, a Discord-native AI companion, and Stripe billing.

Role: Design + build + operate
Client: Sage Ideas (Internal)
Category: Fintech
Status: Operational

DB Tables

185

API Endpoints

Test Suites

Billing Incidents

Living architecture

Surface ⇄ System

Nexural is presented as both the product people touch and the operating system underneath it: UI, data model, integration path, evidence, and outcome.

Build something like this

01Visible productScreenshots and product frames show the user-facing surface without pretending concept art is production proof.
02Operating architectureThe case includes a system map so the architecture is visible, not buried in prose.
03Evidence registerMetrics, build logs, diagrams, CI artifacts, and links separate actual work from agency theater.
04Commercial pathThe page routes qualified buyers toward a matching build, automation, or lab entry.

// scroll to x-ray the build

Nexural product surface — The full Nexural surface area: trading platform, Discord-native AI bot, billing, real-time market data, and the seven services that talk to each other through typed contracts.

System map — The full Nexural surface area: trading platform, Discord-native AI bot, billing, real-time market data, and the seven services that talk to each other through typed contracts.

case flow

Surface ⇄ System

A case study should prove both layers: the surface people see, and the system that keeps the product alive after launch.

Nexural operating map

The diagram is intentionally simplified: it shows the buying logic and operating path, not a decorative fantasy architecture.

client

Sage Ideas (Internal)

Receipts before claims.

This page separates shipped surface, system map, real metrics, and available artifacts so the work can be inspected instead of just admired.

proof assets

Screens, gallery, artifacts

screens

Real product surfaces

artifacts

Available during discovery

Primary evidence

185 tables. 69 endpoints. One engineer.

DB Tables

185

DB Tables

185

API Endpoints

Test Suites

Billing Incidents

AI Queries/Week

200+

OSS Templates

Surface

Product screenshots and interface frames show the user-facing layer. If real assets are unavailable, the page says so instead of dressing mockups as production proof.

System

Architecture diagrams, build logs, and artifacts make the hidden operating layer visible to technical buyers.

Explore the Lab entry for Nexural

motion proof mapnexural · real-system storyboard

Trading product operating loop

Surface, system, proof, route.

This storyboard turns the case study into a moving operating map: the buyer sees what was built, where the system lives, and which proof points are actually available.

tables: 185
endpoints: 69
test suites: 61

01// the problem

What was broken.

Most trading tools fall into one of two categories: consumer apps so simplified they're useless for serious traders, or enterprise platforms so complex they require an ops team to configure. There was no middle ground for the technically sophisticated individual trader who wanted full control without the overhead.

Nexural was built to fill that gap — a production-grade fintech platform with real-time execution, portfolio tracking, a Discord-native AI companion, and a subscription billing layer that doesn't break on webhook retries.

The challenge: building a system at this scale — 185 relational database tables, 69 API endpoints, real-time market data ingestion, and a Stripe integration that needs to survive every edge case — without a dedicated backend team, a QA department, or a six-month runway for architecture review.

02// the approach

How it was built.

PostgreSQL on Supabase with Row-Level Security for multi-tenant isolation and real-time subscriptions via Supabase channels for live portfolio updates. Backend: FastAPI (Python) — async-first, typed with Pydantic, organized into domain-bounded modules. Frontend: Next.js with server components for data-heavy pages and client components for interactive trading UI.

Real-time via WebSocket connections for live price feeds; Supabase realtime for portfolio state synchronization. Stripe with idempotent webhook handlers, subscription lifecycle management, and metered feature gating. Discord bot backed by OpenAI GPT-4 with tool-calling for portfolio queries, market commentary, and alert management.

The philosophy: don't build features until the foundation is right. The first two weeks were data modeling — no UI, no API, just entity-relationship design, understanding where the RLS policies needed to live, and mapping every Stripe event to a database state.

03// architecture

The system map.

How the pieces talk to each other.

04// the numbers

Measured, not asserted.

The real figures from the engagement, printed verbatim. Bars are scaled against the largest comparable magnitude in the set — a secondary cue, never the source of truth.

metric · valuescale 0 – 200

DB Tables: 185
API Endpoints: 69
Test Suites: 61
Billing Incidents: 0
AI Queries/Week: 200+
OSS Templates: 3

05// built ui

Selected screens.

Real product surfaces from the engagement — not stock illustrations.

Nexural dataset and pipeline dashboard listing 47 datasets and a 1.2TB ML store

01 / 02

Datasets dashboard — 47 sources, RLS-isolated, real-time ingestion telemetry on every row.

06// evidence

What it actually looks like.

Architecture diagrams, CI runs, and dashboards from the engagement.

The full Nexural surface area: trading platform, Discord-native AI bot, billing, real-time market data, and the seven services that talk to each other through typed contracts.

61 test suites green on every PR. End-to-end coverage across trading flows, billing webhooks, and Discord bot interactions — the regression net that lets one engineer ship into production.

Performance, accessibility, and best-practices budgets enforced in CI. The dashboard fails the build if a PR regresses the user-facing surface — not after launch.

07// the build log

What shipped.

The verbatim ship record, given timeline structure.

log · entry 01
185 PostgreSQL tables with full RLS policy coverage. 69 REST/WebSocket API endpoints (FastAPI). Real-time portfolio dashboard (Next.js + Supabase realtime). Trade execution interface with order management. Discord AI bot: portfolio queries, alerts, natural-language market commentary.
log · entry 02
Stripe billing: subscription tiers, metered usage, trial periods, webhook idempotency. 61 test suites: unit, integration, E2E, contract, and security tests. CI/CD pipeline with GitHub Actions — no PR merges without passing gates.
log · entry 03
The Stripe webhook layer is built on idempotency keys and event deduplication — a pattern now templated into micro-saas-starter on GitHub. The Discord bot uses function-calling to query the live portfolio API, meaning it responds to "how is my AAPL position" with real data, not hallucinated commentary.

08// the outcome

What it proved.

Platform operational: live, stable, serving active users. Zero billing incidents since launch — the idempotent webhook architecture holds. AI bot handling 200+ natural-language portfolio queries per week.

61 test suites provide regression coverage for all critical paths. Architecture patterns extracted into 3 open-source templates used in subsequent projects.

A single engineer, with the right architecture discipline and AI-assisted development workflow, can build and maintain a system at this complexity level. The 185-table schema isn't a vanity number — it's a data architecture that needed to be right before anything was built on top of it.

09// artifacts

Available on request.

Database schema overview (anonymized)
Webhook idempotency pattern documentation
Discord bot architecture diagram
CI/CD pipeline configuration template

// references

Talk to people on this work.

No fabricated quotes. Reference contacts are shared during discovery, with both parties' consent.

Reference available

Engineering lead

Fintech · 5 years

Worked alongside on production trading systems for 5+ years. Available for technical reference calls — code quality, on-call discipline, incident behavior.

Reference call shared during discovery, both consenting.

Reference available

Founder

Studio engagement

Engaged Sage Ideas for a Ship + Operate combination. Willing to talk about scope discipline, timeline accuracy, and what handoff actually looked like.

Reference call shared during discovery, both consenting.

Build something like this Explore the Lab entry for Nexural

“185 tables isn't a vanity number. It's the data model that needed to be right before anything else could be built on top of it.”

// build log · entry 04

// honesty

What almost happened.

Every project has near-misses — decisions that, if we'd kept going, would have shipped a hole. This is the diff between the version that almost made it to prod and the version that did.

// near-miss · 01diff

beforeWebhook handler retries on Stripe were going to double-charge in 6 of the 47 event types we cared about.

afterBuilt an idempotency table keyed on (event_id, customer_id) with a transactional INSERT-OR-NOOP and replay the side-effect from the persisted row.

cost~$0 in customer refunds. Zero billing incidents since launch.

// near-miss · 02diff

beforeFirst architecture sketch put RLS on the API layer — the application would enforce tenant isolation in code.

afterMoved every multi-tenant table to Postgres RLS with role-bound policies. The DB refuses cross-tenant reads even if the app forgets to filter.

costTwo extra weeks. One catastrophic bug class permanently impossible.

// near-miss · 03diff

beforeReal-time portfolio was about to be polled every 5s from the client — 12 RPS per active session.

afterSupabase realtime channels with row-level filters; client subscribes, server pushes. Same data, ~0.2 RPS per session.

costServer bill stayed under $80/mo at 200+ AI queries/week.

// from the repo

Inline excerpts.

Trimmed, but real. The patterns that made the system survive retries, multi-tenant queries, and a bot that won't hallucinate.

Stripe webhook idempotency

python

# webhook_handler.py — production excerpt
@router.post("/stripe/webhook")
async def handle_stripe(req: Request, db: Db):
    event = stripe.Webhook.construct_event(
        await req.body(),
        req.headers["stripe-signature"],
        STRIPE_WEBHOOK_SECRET,
    )

    # idempotency: insert-or-noop on (event_id) primary key
    inserted = await db.fetchval("""
        INSERT INTO stripe_events (event_id, type, payload, status)
        VALUES ($1, $2, $3, 'pending')
        ON CONFLICT (event_id) DO NOTHING
        RETURNING event_id
    """, event["id"], event["type"], event.data.object)

    if inserted is None:
        # we've seen this event. ack and exit.
        return {"ok": True, "replay": True}

    # side-effect runs exactly once, inside a transaction
    async with db.transaction():
        await process_event(event, db)
        await db.execute(
            "UPDATE stripe_events SET status='processed' WHERE event_id=$1",
            event["id"],
        )
    return {"ok": True}

// Replay-safe by construction. Same event delivered twice does nothing the second time.

Row-level security on portfolios

sql

-- migrations/2026_03_rls_portfolios.sql
ALTER TABLE portfolios ENABLE ROW LEVEL SECURITY;

CREATE POLICY portfolios_owner_select
  ON portfolios FOR SELECT
  USING (owner_id = auth.uid());

CREATE POLICY portfolios_owner_modify
  ON portfolios FOR ALL
  USING (owner_id = auth.uid())
  WITH CHECK (owner_id = auth.uid());

-- Even an authenticated client running raw SQL via PostgREST
-- cannot read another user's row. Verified in 14 contract tests.

// Tenant isolation enforced by Postgres, not by the application.

Discord AI bot — function-calling against the live API

typescript

// bots/discord/tools.ts — production excerpt
export const tools = [
  {
    type: 'function',
    function: {
      name: 'get_position',
      description: 'Fetch a live position for the calling user',
      parameters: {
        type: 'object',
        properties: { symbol: { type: 'string' } },
        required: ['symbol'],
      },
    },
  },
] as const

export async function execute(tool: ToolCall, ctx: BotCtx) {
  if (tool.function.name === 'get_position') {
    const { symbol } = JSON.parse(tool.function.arguments)
    // Real API call — same auth, same RLS as the web app.
    return await api.get('/positions/' + symbol, { token: ctx.userToken })
  }
  throw new Error('unknown tool')
}

// The bot does not hallucinate positions. It calls the same endpoint the dashboard does.

A trading platform built like an institution. Run by one person.

Surface ⇄ System

Receipts before claims.

185 tables. 69 endpoints. One engineer.

Surface, system, proof, route.

What was broken.

How it was built.

The system map.

Measured, not asserted.

Selected screens.

What it actually looks like.

What shipped.

What it proved.

Available on request.

Talk to people on this work.

Engineering lead

Founder

What almost happened.

Inline excerpts.

Engage

Proof

Learn

Studio