Product build
A defined product from problem through first production release.
Written scope. Named operators. A handover.Engineering services
Software you can operate.
Selected teams only. Products come first — services support the studio, they do not replace it. Scope is written down. Handover leaves a system behind, not a retainer that never ends.
Who we takeSelected operators
How it startsWritten scope
Who runs itYour team
Commercial terms
An engagement has a boundary.
- Written statement of work
- You operate the result
- Confidentiality before the build
- No custody of funds
- Written scope
Work starts from a statement of work: problem, non-goals, operators, and what handover means. We do not invent a programme to fill a calendar.
- You operate the result
Software is delivered for you to deploy and run. The studio is not a hosted processor, a staff-augmentation bench, or an account team you cannot reach.
- Named engineers
You work with the people designing and building the system. Architecture notes and trade-offs live in writing so the product can be maintained after the first release.
- Clear commercial bounds
No custody of funds. No legal, tax, or compliance advice. England & Wales. Confidentiality and IP are agreed before a build, not after a demo.
Product Development.
Turn an idea into a production-ready digital product.
From problem framing and information architecture through interface design, engineering, and deployment. The goal is a product that can be operated, not a prototype that only works in a demo. Scope is written before the build starts. Handover includes how the system is run, not only how it looks.
You receive the artifact, the deploy path, and a note the operator can run without us.
- 01
A scoped product with a clear purpose
- 02
Working application and data model
- 03
Deployment path the team can run
- 04
Documentation sufficient to continue the work
Who it is for
- Founders with a specific workflow to productise
- Operators who need a first production cut, not a pitch deck
- Teams who will own the software after we leave
Not this
- An unbounded discovery retainer
- A clickable prototype with no data model
- A white-label of a generic SaaS template
Frontend Engineering.
Build modern React and Next.js applications with maintainable architecture.
Marketing surfaces, dashboards, and product UIs with a component system that can grow. We care about structure, accessibility, and how the interface maps to real workflows. The frontend is treated as part of the product — not a skin applied after the API exists.
Components, routes, and states are documented against the jobs they serve.
- 01
Component systems that stay consistent
- 02
App Router / Next.js product surfaces
- 03
Responsive layouts that hold up in production
- 04
Interfaces that match the underlying domain
Who it is for
- Product teams who need an application shell that can last
- Operators who live in dashboards more than in decks
- Studios replacing a patchwork of marketing pages and admin screens
Not this
- A theme purchase with no information architecture
- Animation as a substitute for workflow
- A design system nobody will maintain
Web3 Development.
Build blockchain-enabled applications and integrations.
Wallet flows, chain adapters, and product experiences that connect on-chain capabilities to software people can actually use. We do not treat Web3 as a branding exercise. Signing boundaries are written: who holds keys, who runs infrastructure, and what the studio never custodians.
You keep the keys. We leave software, a signing note, and the operational boundary in writing.
- 01
Wallet and network integration where needed
- 02
Payment and signing flows that match the architecture
- 03
Clear operational boundaries (who holds keys, who runs infra)
- 04
Interfaces that hide unnecessary protocol noise
Who it is for
- Businesses deploying self-hosted payment or settlement software
- Teams who already operate wallets, RPC, and compliance themselves
- Products where the chain is a capability, not the entire pitch
Not this
- A hosted processor or custodial wallet service
- Token launches, market-making, or fundraising theatre
- Legal, tax, or regulatory advice
Custom Software.
Build internal tools and business systems around your actual workflow.
Operational software, integrations, and automation designed around how the team already works. We avoid generic templates that force the business to adapt to the tool. Permissions, audit trails, and the morning-after close are part of the brief.
Roles, states, and integrations are written so the floor can run without a private workbook.
- 01
Tools mapped to real processes
- 02
Integrations with existing systems
- 03
Permissions and auditability where required
- 04
A system someone on the team can maintain
Who it is for
- Operations teams leaking hours into spreadsheets
- Companies that already have a system of record and need a command layer
- Desks that run after midnight and cannot wait on a vendor queue
Not this
- A second ERP sold as a 'digital transformation'
- Staff-augmentation to maintain a legacy stack forever
- A no-code experiment with no owner
Technical Consultation.
Independent technical advice on architecture, payments, build-versus-buy, and scope — delivered in writing.
An experienced outside view on the technical decision in front of you: how a payment flow should be designed, whether to build, buy, or rent, whether a system is ready to launch, or how to scope a first release. Written Q&A, asynchronous reviews, and decision briefs end with a written recommendation, a ranked risk list, and next actions with owners. Everything runs in writing over the text channel you choose, and scope and fee are agreed in writing before anything starts.
You own the written outcome. We offer a check-in after thirty days; any build is scoped separately.
- 01
A written recommendation with the reasoning behind it
- 02
A ranked risk register and the smallest fix for each item
- 03
A decision record you can file and revisit
- 04
Next actions with suggested owners
Who it is for
- Founders and engineering leads facing a specific technical decision
- Teams evaluating a vendor, a gateway, or an inherited codebase
- Operators who want a second opinion before a build or a launch
Not this
- Legal, tax, or compliance advice
- A rubber stamp for a decision already made
- An open-ended retainer with no boundary
EngagementsOutcome Slice Term Surface Capability Operations
Typical commercial shapes.
We do not publish package prices unless a standardized offering exists. Fit is decided in writing before anyone opens a repository.
Feature development
A focused slice on an existing product — API, dashboard, or workflow.
One boundary. One release. No programme to fill a quarter.Technical partnership
Ongoing engineering alongside your team for a limited, explicit scope.
Calendar-bounded. Reviewed in writing. Not a bench.Frontend engineering
Interface, design system, and application shell work in React / Next.js.
The UI is part of the product, not a skin.Web3 integration
Chain, wallet, or payment infrastructure wired into a real product.
You hold keys. We do not custody funds.Internal tool development
Software for operations, not a public marketing site.
Mapped to the desk that will run it.Process
How an engagement runs.
Four cuts. Each one leaves a written artifact. Demos are not a substitute for a system in the environment that matters.
- 01
Frame the problem
We start with the use case, the constraints, and who the software has to serve. Features come after the problem is clear.
A written problem, operator, and non-goals — not a feature dump.
- 02
Design the smallest complete product
A focused scope that can ship. Interfaces, data model, and operational shape are designed together — not as afterthoughts.
A bounded scope: screens, data, and how the system is run.
- 03
Engineer for production
Architecture, authentication, deployment, observability, and documentation are part of the build, not a later phase.
Software that can be deployed, observed, and handed over.
- 04
Ship, then iterate
We prefer a working system in a real environment over a long sequence of demos. Feedback from use drives the next cut.
A release in the environment that matters, then a next cut from use.
Where this shows up
The kinds of software we actually ship.
- SaaS products
Focused software around a specific workflow — dashboards, billing-adjacent tools, and operational apps.
Operator dashboardsWorkflow appsBilling-adjacent tools - Developer tools
APIs, gateways, and infrastructure that make a technical workflow easier to run.
Versioned APIsPayment gatewaysSelf-hosted services - Web3 products
Blockchain-enabled applications where the chain is a capability, not the entire pitch.
Wallet flowsChain adaptersStablecoin payments - Business software
Internal tools and systems shaped around how a company actually operates.
ApprovalsIntegrationsOperational records
Capabilities
Tools we list because we use them.
Frontend
ReactNext.jsTypeScriptComponent systemsResponsive product UI
Product engineering
SaaS applicationsDashboardsAPIsInternal toolsWebhook-driven flows
Web3
Wallet integrationsChain adaptersPayment gatewaysSigning boundaries
Infrastructure
DockerPostgreSQLCloud or VPS deployBackground jobsObservability
Not included
- Generic agency retainers with no product outcome
- Staff-augmentation benches disguised as a studio
- Hosting or custodial services presented as if they were the product
- Legal, tax, or compliance advice
- Unbounded 'digital transformation' programmes
Governing law
Commercial terms are agreed in writing. The studio does not provide legal, tax, or compliance services. England & Wales.
FAQ
Questions operators actually ask.
Is this a product company or an agency?
A product-focused digital studio. The catalog is the primary long-term asset. Services are a secondary channel for selected engagements — not the whole brand.
Do you only build Web3 products?
No. We work across SaaS, developer tools, business software, and Web3 where the problem actually requires it.
Can we hire you for a custom project?
Yes, for selected teams. Write what you are building, what you need help with, and any hard constraints. We respond when it is a good fit.
Do you offer technical consultation?
Yes. We advise selected teams on architecture, payments and Web3 integration, build-versus-buy decisions, security readiness, and scoping — as written Q&A, asynchronous reviews, and decision briefs that end in a written recommendation. We work entirely in writing over the text channel you choose — no calls — and agree scope and fee in writing first.
Where do product pricing and docs live?
With each product. Studio pages introduce the software and its status. Pricing, licenses, and documentation belong to the product experience as they are published.
Is StablePay a hosted payment processor?
No. StablePay is self-hosted software. You deploy and operate it. The studio does not hold customer funds or run customer wallets as a service.
Can we read client work before we talk?
Yes. Start with Vellum Markets, Halcyon Freight, and Aperture Collective on the Work page. Each study names the team, the problem, the stack, and what changed after handover.
Do you provide hosting, legal, or compliance services?
Not as part of the standard studio offering. Customers are responsible for infrastructure, legal, tax, and regulatory requirements in their own jurisdiction.
Write the problem first.
Tell us what the team still runs, who will operate the result, and the constraints that are not negotiable. We will say whether it is a build, a product, or a no.