Customer and trade portals
Logins for your customers, with the pricing, history and documents that belong to them and nobody else. Reordering, account-specific pricing, statements and query handling.
Bespoke platforms
When a website is not the thing you actually need.
Some businesses do not need a better brochure. They need the thing their staff work in every day, or the portal their customers order through. We build those, properly, on the same stack the big software companies use.
Where this sits next to everything else we do.
Most businesses genuinely do not need this, and we will tell you if you are one of them. It is worth being clear about the difference, because the three options below are not tiers of the same thing. They are different products.
| Option | What it is | Right when |
|---|---|---|
| AI Website Builder | A real website, generated and live quickly, that you can edit yourself. | You need a credible site now and the budget is tight. |
| Web design and eCommerce | A designed site or shop, built around enquiries or sales. | The website is the product. You sell or get enquiries through it. |
| Bespoke platform | Software. Logins, data, workflow, integrations, automation. | The problem is how the business runs, not how it looks. |
What we build.
Usually some combination of these four, because a real business problem rarely stays in one box.
Ordering and operations systems
The screens your team actually works in. Orders, stock, batches, deliveries and the admin around them, designed around how the business really runs rather than how software usually assumes it does.
Integrations and automation
Payments, couriers, accounting, messaging and whatever else needs to talk to whatever else. Scheduled jobs that do the routine work overnight instead of somebody doing it by hand.
Dashboards and internal tools
The reporting a business ends up rebuilding in spreadsheets every quarter, made properly once so the numbers come from the system rather than from somebody exporting a CSV.
Case study
A meat wholesaler that outgrew its spreadsheets.
AWhite Meats supply butchers, caterers and restaurants. Like a lot of established trade businesses, the operation had grown around tools that were never designed for it: a price list maintained by hand in Excel, exported to PDF and emailed out a few times a week, and orders arriving by phone and message to be typed up afterwards.
We built them a platform rather than a website. Their customers log in to a portal, see the pricing that applies to their account, and reorder from what they bought last time. The office works in a system that holds the catalogue, the orders, the stock and the paperwork together, instead of holding them in four places that have to be reconciled by somebody at the end of the week.
Around that sit the unglamorous parts that make it usable day to day: card payments through Stripe, credit accounts with terms, invoice queries that go somewhere rather than into an inbox, and alerts to the team the moment an order comes in or stock is approaching its use-by date. Overnight jobs handle the reconciliation and health checks so nobody starts the morning by checking whether anything broke.
Their public site was rebuilt alongside it, on the same codebase, so the trade site reads from the same live catalogue rather than being a separate thing that goes out of date.
Customer portal
Account pricing, reordering, statements and queries
Trade price list
Replaced a hand-maintained Excel and PDF email round
Payments
Stripe card payments alongside credit accounts and terms
Operations
Orders, stock, batches and use-by tracking in one system
Alerting
The team pinged on new orders, payments and stock issues
Public site
Rebuilt on the same codebase, reading the live catalogue
We run our own platforms too.
Which matters more than it sounds. When we recommend an approach, it is usually because we have already run it ourselves for months and watched what it does at scale, rather than because we read about it.
Vivid Repairs
Our own technology publishing site, running on the same stack we would build yours on. It publishes continuously, maintains its own internal linking and runs its health checks on a schedule, with over a hundred scheduled jobs behind it.
Read what eleven months of it looked likeThe AI Website Builder
The builder behind our own studio product is a platform in its own right: it generates, previews and deploys real websites, handles subscriptions and gives customers a portal to manage what they own.
See the builderWhat we build it on, and why.
You do not need to care about any of this. It is here because the people who do care usually want to know before they commit, and because the answer says something about whether the thing will still be maintainable in three years.
Next.js
The application framework. Fast pages, real routing, server rendering where it helps.
Vercel
Hosting and scheduled jobs. Deploys are atomic and roll back cleanly.
Postgres
A real relational database, because business data has relationships and constraints matter.
Stripe
Card payments and subscriptions, handled by people whose whole job is card payments.
TypeScript
Types across the whole codebase, so a change in one place fails loudly in the other.
You own the code. If you ever want to take it elsewhere, it goes with you, and it is written in something a normal development team will recognise rather than a proprietary builder only we can maintain.
When this is the wrong answer.
Worth talking to us
- Your team runs the business out of spreadsheets that no longer cope.
- Customers order by phone or email and somebody re-types it afterwards.
- You pay for software that does most of the job but not the part that matters.
- Two systems hold the same data and disagree with each other.
- A person spends hours a week doing something a computer should do overnight.
Probably not this
- You need a good website that brings in enquiries. That is web design.
- You want to sell products online in a standard way. That is eCommerce.
- Off-the-shelf software already does it well and you have not really tried it.
- The real problem is process rather than tooling, and software would just cement it.
We would rather say so at the first conversation than build you something expensive you did not need.
Tell us the problem, not the solution.
The most useful first conversation is about what is going wrong in the business, not about what software you think you need. We will tell you honestly whether this is worth building, and what it would take.