Who it is for
Businesses that sell, book or run memberships online, and founders launching a subscription product.
Home / Capabilities / Full-Stack Development
Capability 02
Web platforms that take the order, not just the click
For businesses whose website has to do real work. If yours only shows information while sales, sign-ups and admin happen by hand, we build the whole platform and test it the way your customers will use it.
Who this is for, and what you get
The problem
A nice-looking site that stops at a contact form leaves your team doing the rest by hand, and stitched-together plug-ins can break at checkout.
What you get
A live platform with accounts, payments and an admin area your staff can use, built and tested by one team.
What we build
What this covers
Customer platforms
Sign-in, plans and member areas, where each customer sees what they have paid for and nothing else.
Commerce and ordering
Online ordering and shops on hosted checkouts, with prices held on the server so a browser cannot change them.
Learning and community
Courses, progress tracking, communities and members-only content.
SaaS products
Software you sell by subscription, with plans, billing, usage tracking and an admin console.
Dashboards and portals
Client portals and internal dashboards that put live numbers on one screen.
Fast marketing front ends
Pages built to load fast, be found in search and work for everyone, attached to the real product.
Sample architecture
How it fits together
Front end
What the customer sees and taps. This sample form sends only the item chosen, never a price.
- Static front endServed from a CDN
- Sign-inClerk or Supabase Auth
- React
- Next.js
- Astro
checkout.astro
<form method="post" action="/api/checkout">
<input type="hidden" name="item" value={id} />
<button>Pay securely</button>
</form>Server
Where your rules run, out of the customer’s reach. This sample looks the price up in your own list.
- FunctionsBusiness rules
- Signed webhooksVerified before use
- Node.js
- TypeScript
checkout.ts
const item = catalogue[body.item];
// The server sets the price, never the browser
return checkout.create({ amount: item.price });Data
Where records are kept. This sample rule tells the database to show customers only their own orders.
- Postgres + RLSRow-level security
- Postgres
- Supabase
- Prisma
orders.sql
alter table orders enable row level security;
create policy "own orders" on orders
for select using (auth.uid() = user_id);Hosting
Where the platform lives online. This sample setting sends server requests to the right place.
- Static front endServed from a CDN
- Hosted checkoutSquare, Stripe, Whop
- Netlify
- Fly.io
netlify.toml
[[redirects]]
from = "/api/*"
to = "/.netlify/functions/:splat"
status = 200The diagram, step by step
Follow one purchase from click to confirmation
Picture a sample pottery studio selling class passes online. Pick a layer in the panel above to see its parts and a short piece of sample code. The steps below follow one customer buying one pass.
-
The page appears quickly
- What happens
- The customer opens the site. Pages come from a CDN, a network of servers that keeps copies close to the visitor.
- Who does it
- The static front end.
- Why it matters
- Fast pages on a phone, because they are ready before anyone asks for them.
-
The customer signs in
- What happens
- They create an account or log in, using a sign-in service that specialises in it.
- Who does it
- Clerk or Supabase Auth.
- Why it matters
- The studio never has to build or guard its own password system from scratch.
-
The server sets the price
- What happens
- The browser only says which pass was chosen. A server function looks up the real price in a trusted list.
- Who does it
- Functions: small programs that hold your business rules.
- Why it matters
- Without this, someone could edit the page and pay $1 for a $100 pass.
-
The customer pays on a hosted page
- What happens
- They are sent to a checkout page run by the payment provider, and enter their card there.
- Who does it
- Square, Stripe or Whop.
- Why it matters
- Card details never touch your website.
-
The payment is confirmed
- What happens
- The provider sends a signed message, called a webhook, to say the payment worked. We check the signature first.
- Who does it
- The signed webhook handler.
- Why it matters
- A fake “paid” message is rejected, so nobody gets a free pass.
-
The order is stored safely
- What happens
- The order is saved. Row-level security (RLS) means the database itself only shows people their own records.
- Who does it
- The Postgres database.
- Why it matters
- Even if a screen has a bug, one customer cannot read another’s orders.
-
Everyone is told
- What happens
- The customer gets a confirmation, and the studio sees the booking in its admin area.
- Who does it
- Email and messaging services, triggered by the server.
- Why it matters
- No one has to check a dashboard to learn a sale happened.
Commerce and ordering
From code to a working checkout
Online ordering and shops on hosted checkouts, with prices held on the server so a browser cannot change them.
<article class="order">
<h3>Your order</h3>
<Line item="Sample item" />
<button>Pay securely</button>
</article>.order { border-radius: 18px; }
.order button {
background: var(--gold);
}const { total } = await api.quote(cart);
render(total); // priced on the serverYour order
Sample item$24.00
Total$24.00
Pay securelyHow to read this demo
What the three stages show
The left side shows sample code and the right side shows what a customer would see. Pick a stage or press Replay. No real payment happens here. The item and price are made up.
-
Structure
- What happens
- The code lists what belongs on the screen: a title, an item and a button.
- Who does it
- Our developers, in the front-end code.
- Why it matters
- The page works before it is styled, and screen readers can follow it.
-
Look
- What happens
- A second layer of code sets corners, spacing and colour, so it matches your brand.
- Who does it
- Our developers, following your design.
- Why it matters
- A customer sees a checkout that looks like yours and feels safe to use.
-
Live price
- What happens
- The screen asks the server for the total and displays the answer. The dashes turn into a real number.
- Who does it
- The server, never the browser.
- Why it matters
- The price shown is the price charged, and it cannot be edited from the page.
Process
How the work runs, step by step
- 01
Scope the product
We work out who uses it, what they pay for, and what has to be true on launch day.
- Who does it
- You and our team.
- What you get
- A clear list of what launch needs, so the first version is not padded with extras.
- 02
Design the flows
We plan the sign-up, purchase and admin journeys, screen by screen, before any styling.
- Who does it
- Our team, with your feedback.
- What you get
- Confusing steps get fixed before they are expensive to change.
- 03
Build and integrate
We build the database, server rules, payments and front end, and put them on a private preview link.
- Who does it
- Our team. You try the preview as it grows.
- What you get
- You use the real thing while it is being built.
- 04
Test like a customer
Scripted browser tests click through the real paths. Then we launch and watch how it runs.
- Who does it
- Our automated tests and our team.
- What you get
- Broken checkouts and dead buttons get caught before customers meet them.
The stack
Tools we run in production
We pick for your system. These are what we work with most in this area.
You do not need to know these names. In plain terms: React, Next.js and Astro build the pages, Node.js and TypeScript run the server, Postgres and Supabase store the records, Clerk handles sign-in, Stripe, Square and Whop take payment, Netlify and Fly.io host it, and Puppeteer runs our automated browser tests.
- React
- Next.js
- Astro
- TypeScript
- Node.js
- Supabase
- Postgres
- Prisma
- Clerk
- Stripe
- Square
- Whop
- Netlify
- Fly.io
- Puppeteer
Deliverables
What you get
- Live production site or app
- Source code and repository access
- Admin tools for content, orders or members
- Payment setup, including verified payment confirmations
- Functional and accessibility test results
- Launch checklist and handover
Related work
Where we have built this
Food service and entertainment
The Fried Hangover
Three disconnected codebases merged into one live platform for a Phoenix vegan food truck: online orders, a music and goods shop, loyalty, reviews and one safe checkout.
Online education and membership
KinglyVault
A membership platform for AI courses, tools and community that links safely to each member's own InfiniBot, with no network ports to open.
Generative media software
FlyPic
An AI image and video studio where every job runs on the user's own provider account, with long jobs finished safely in the background.
FAQ
Common questions
Which technology will you use?
The one that fits. Simple platforms use pre-built pages with small server functions. Full products use Next.js or React with a Postgres database. We pick for your needs and for how easily it can be maintained.
How do you keep payments safe?
Card details stay on the provider’s hosted checkout. Prices are calculated on the server from a trusted list, and payment confirmations are checked by signature before an order is trusted.
Can you take over an existing app?
Yes. We start with a technical review so you know what state it is in, then fix, extend or migrate it.
Do you build mobile apps?
Yes. InfiniBot has a companion mobile app built with Expo and React Native, and we can build the same way for your product.
Talk to us about full-stack development
Answer a few questions and send them to us. We will tell you what we would build, and what you do not need.