Studio

A digital studio built around products.

We design, engineer, and ship software products — and we work with selected teams when the problem is specific enough to leave a system behind. The studio opened in 2019. It is still small on purpose.

Why the studio exists

Useful software after launch.

The studio exists to build software that stays useful after launch. Too much digital work stops at a presentation, a prototype, or a rented platform. We would rather own a focused catalog — StablePay, Northframe, Meridian — and take on the engineering required to keep those products honest in someone else's week.

How we think

Product-first means the catalog comes before the services page. Engineering-led means interfaces, APIs, deployment, and operations are designed as one system. We sit between a product company and a software studio — not a freelancer portfolio, and not a generic web agency.

The technologies we list are tools we actually use: React, Next.js, TypeScript, APIs, Docker, PostgreSQL, and chain integrations where a product requires them. We do not list a stack for decoration.

What we believe

Four working beliefs.

Products are the proof

A studio is judged by what it ships. Catalog software and named engagements — not a slide of logos — are how we ask to be evaluated.

Ownership beats rental

Where it matters, customers should control their infrastructure, data, and operational environment — especially for payments and core systems.

Clarity is a feature

APIs, dashboards, and copy should be understandable. Complexity is allowed only when the problem requires it.

After the demo matters

Deployment, backups, upgrades, monitoring, and support paths are part of the product. Shipping a screen is not the same as shipping a system.

How we work

A small, direct practice.

Selected engagements

We take on a small number of projects so the work stays focused. Fit matters more than volume.

Direct collaboration

You work with the people designing and building the software. No account-layer theatre.

Written decisions

Architecture notes, trade-offs, and scope live in writing so the product can be maintained after the first release.

Honest scope

If something is not a good fit, or is not ready to build, we say so. We do not invent a programme to fill a calendar.

Process

From problem to production.

  1. 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.

  2. 02

    Design the smallest complete product

    A focused scope that can ship. Interfaces, data model, and operational shape are designed together — not as afterthoughts.

  3. 03

    Engineer for production

    Architecture, authentication, deployment, observability, and documentation are part of the build, not a later phase.

  4. 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.

Principles

Product-first. Engineering-led.

Start with the problem

We build around a real use case instead of starting with a feature list or a trend.

Keep the product focused

Every product should have a clear purpose and a reason to exist. Scope is a design decision.

Build for production

Architecture, security, deployment, monitoring, and maintainability are part of the product.

Ship and learn

Products improve through real usage, written feedback, and iteration — not through infinite planning.

Avoid unnecessary complexity

Good software should be understandable. We add moving parts only when the problem requires them.

What we don't do

Boundaries keep the work honest.

  • 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
FAQ

Common questions.

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.

Have something worth building?

Whether you're looking for a software product or need a team to help build one, let's talk.

Free apps from the studio. Enter your email, get a private download link. Free for personal use.

Get them free

Have a product to sell? We review, list, and sell it for you — you keep 90% of every sale.

Apply to sell with us