Skip to content

AI-Native Design Engineering: A Payment Product in Five Days

Designing and building Pulse’s React frontend so a prospective partner could evaluate checkout, payment operations and developer integration in one working demo.

In this case study
At a glance

Shiga had the payment capabilities. A prospective partner needed to see them working together.

Company
Shiga, Pulse’s parent company
Industry & platform
Fintech, Web3, B2B, Web, SaaS
Role
Product design + React frontend delivery
Team
Product, Engineering, Business Development
First build
July 2026, five working days
Tools
Figma, Codex, Helium React, Storybook, Mintlify

Pulse brought Shiga’s payment capabilities into a business product: checkout for customers, operations for partner teams and integration tools for developers.

Project TLDR:

  • I designed and built the React frontend, using Helium components and AI-assisted implementation.
  • Engineering connected the backend APIs. The team tested and presented the integrated product on day five.
  • The recorded demo helped secure Piggyvest as a partner.
Handoff and first-demo outcome

Five working days to show Pulse working

Shiga already offered on-ramp, off-ramp and payments through its consumer product, Enta. Pulse brought those capabilities together for businesses, helping them accept crypto and settle in fiat.

Business Development found the prospective partner, Piggyvest, managed the relationship and arranged Friday’s evaluation. The evaluation focused on its investment use case: accepting a payment inside the partner’s product and giving its team visibility.

My PM and I protected three jobs for the demo: complete a payment, understand its status and see how to integrate. Checkout, the partner dashboard and developer guidance had to support the same evaluation.

Partner clarification narrowed the scope

Known at the start
Partners needed embedded payments, operational visibility and a clear integration path. I used the partner conversation, Business Development context, payment knowledge and Engineering’s API constraints to define those jobs.
Decided for the demo
I defined the initial roles and permissions. We deferred self-serve onboarding to protect Friday’s evaluation, so partners would still need help getting set up.
Learned afterward
Partners later requested clearer payment failure reasons. That feedback belongs to the work beyond the first demo.

Four roles across one payment journey

The customer pays inside the partner’s product. Pulse converts the payment to fiat and settles to the partner’s account, while the partner’s team monitors payments and settlements.

Admin

Set up the team, settings and operational access.

Developer

Configure API keys, webhooks and test/live integrations.

Viewer / Operations

View transactions, payment status and performance with read-only access.

Customer

Pay inside the partner’s product through embedded checkout.

Partner Operations Dashboard
Developer Integration Portal
Embedded Checkout SDK

Later product capability included USDC, USDT or BTC on 20+ networks. This describes the evolved product, not the scope delivered in five days.

Helium made the Figma design reusable in code

I converted the Figma system into React components and documented them in Storybook. Design, Codex and Engineering could work from the same reference.

Figma properties became React props. The Button mapping defined hierarchy and size, along with default, hover, focus and disabled states. Reusing established patterns gave me time to design and QA the product’s flows and features.

The Button component and its variants in Storybook.Explore Storybook
Current Helium reference

One Button, reusable props

View in Storybook 
import {
  Button,
} from '@helium/react';

<Button
  hierarchy="primary"
  size="lg"
>
  Button CTA
</Button>

Figma’s “Primary” hierarchy maps to hierarchy="primary", and its “lg” size to size="lg". Hover and keyboard focus use the component’s CSS states.

Live canvas from the maintained Storybook. “Button CTA” is its example label.

AI-assisted implementation still needed design review

I set the product structure and behaviour: product priorities, Figma flows, written states and the existing Helium React components. Codex assembled the frontend in smaller implementation steps so I could review each part as it took shape.

Taking on the build also made me responsible for checking its behaviour before handing the code to Engineering. Product, Business Development and Engineering reviewed the working flow, and I directed corrections into the next build.

The later transactions view shows the operational surface: find a transaction, trace the payment and inspect its status.

Checkout, operations and docs supported the same evaluation

Explore the later product and repository examples below. These surfaces developed beyond the first five-day demo.

PRODUCT.md

The product brief for the build

The brief defined a frontend prototype and role permissions. For example, developers could access transactions, API keys, webhooks and their profile, with read-only access to customization.

DESIGN.md

Components and behaviour

Use @helium/react before creating a local control. Define how controls work: sorting applies to the complete filtered dataset before pagination.

These are later repository examples, not a record of everything shipped in the first five days. PRODUCT.md opens the complete BUILD_PROMPT.md.

The demo helped secure Piggyvest as a partner

I handed over reviewed React code for API integration. Frontend engineers connected the backend APIs; testing and iteration continued through the partner demonstration.

  1. Day 3

    Frontend ready for review

    I reviewed the working frontend with the team and iterated on their feedback.

  2. Day 4

    Connected to backend APIs

    Frontend developers connected the APIs. More end-to-end tests followed.

  3. Day 5

    Testing and demo day

    We continued testing and presented the integrated product to the partner.

The first build gave the partner a working product to evaluate. The recorded outcome was that the demo helped secure Piggyvest as a partner.

Pulse continued beyond the first partner demo

The website and partner progress below record the work beyond the July build. This is the historical project update from .

I designed and built the Pulse website

At the recorded update, the website was complete on staging and awaiting public launch.

Explore Pulse website
Pulse website, staging at the recorded update.

Partner progress

As of

  • PiggyvestOnboarded
  • 247BetOnboarding
  • SayswitchOnboarding

Where I’d take Pulse next

Reusing Helium gave me time to focus on product behaviour, but the working build still needed review and correction. Checkout, operations and developer guidance had to make sense together before the team could demonstrate the product.

The recorded next-step priorities build on that work:

Test the next iteration with each role
Research setup, payment confidence and failure handling with partner operators, developers and customers.
Measure where partners need help
Track integration time, payment completion and exception-resolution time to guide the next release.
Make partner onboarding repeatable
Build the self-serve setup deferred for the first demo, using partner onboarding to identify where help is needed.
Support new use cases through one SDK
Test which differences belong in partner configuration and which payment behaviours should stay shared.