Software Development App Development AI & Automation Managed IT IT Consulting E-commerce Development SaaS Development API & Integrations SEO · AEO · GEO

Services/Software development

Software development · Custom platforms · White-label for agencies

You won the engagement.There’s a platform at the core.

Custom web platforms, internal tools, and multi-tenant applications — built under your brand and handed over documented and tested. Architecture decisions land in your repo as they’re made, so the code survives the engineers who shipped it.

Partner with us 15 minutes. No pitch.

The work, in seven shapes

What we ship.

Platform work reaches us in a handful of recognisable shapes. Each one below names where it fits and what leaves our hands when it’s done.

Website development

Where it fitsThe engagement reads as a website. The CMS, the integrations, and the page speed are the actual build — and the client's marketing team has to run it without calling a developer every week.

What we shipMarketing sites and content platforms on the CMS the client's team will genuinely use — WordPress, Shopify, Magento, Sanity, Strapi, or Craft. A component library your designers hand off into and the client's editors compose pages from. Core Web Vitals, accessibility, and analytics handled inside the build rather than audited after launch. Your brand on every staging URL, your repo at the end of it.

Custom web platforms

Where it fitsThe client-facing system the whole engagement rests on.

What we shipThe application, its data model, and the admin surface the client's team operates every day. Built so a feature added next year doesn't require re-reading the whole codebase.

Internal tools

Where it fitsThe spreadsheet that quietly runs a department.

What we shipDashboards, approval flows, reporting, and role-based access, shaped around how the team already works. Adoption is the measure, so the tool gets tested with the people who have to live in it.

Multi-tenant applications

Where it fitsOne codebase that has to serve many customers.

What we shipTenant isolation, per-tenant configuration, billing hooks, and the admin oversight the client's team needs. Scaled without rewriting the core every six months.

Migrations & rebuilds

Where it fitsA legacy platform that's in the way of the roadmap.

What we shipA staged migration with the old system live until the new one earns the traffic. Nothing gets switched off without a rollback path. No big-bang cutover, no lost data.

Architecture decision records

Where it fitsSix months later, when someone asks why.

What we shipEvery consequential choice written into your repo as it's made — what we chose, what we rejected, and why. The reasoning is there for whoever picks the work up next.

Tests, docs & runbooks

Where it fitsThe difference between a launch and a handover.

What we shipCoverage on the critical paths, a README that boots the project on a clean machine, and runbooks for anything that pages someone at night. Handover is the state of the repo, not a meeting.

02 / 07

Four phases. Same model, every engagement.

How a platform build runs.

The structure below is the engagement model applied to platform work — where the data model gets decided, where you read the repo, and what happens the week after launch.

Discovery & architecture

First call with a co-founder. What you're building, what's already running and who maintains it, what has to be true twelve months out. Mutual NDA returns the same day.

Scope & data model

The Solve-the-Real-Problem workshop, then a written SOW. The data model gets drawn before any ticket exists, because that's the decision which is expensive to change later.

Build in the open

Branches named after the outcomes they move. Senior review before every merge, a preview deploy on every change, decision records committed as they land. You read the repo whenever you like.

Cutover & stay

Engineered cutover at a quiet hour in your timezone, with monitoring on every critical flow as real traffic arrives. Then the ninety-day Stays Program: Stabilize, Tune, Plan.

Full model on /process03 / 07

What platform work is built with

The stack, narrowed.

The subset custom platform work draws from. We pick per build, in the direction of what your team can maintain after we hand it over.

L01

Frontend

What the client's users touch. Typed, component-driven, and readable by the next team.

ReactNext.jsVueTypeScriptTailwind CSSAstro

L02

Backend

Chosen for what your team can hire for and maintain, not for what we enjoy writing.

Node.jsExpressNestJSDjangoFastAPILaravelRails.NET

L03

Data

The decision that's expensive to change later. Drawn before the first ticket exists.

PostgreSQLMySQLMongoDBDynamoDBRedisSupabaseFirebase

L04

Cloud

Deployed into your client's account, under your client's billing. No lock-in to ours.

AWSGCPVercelCloudflare

L05

CMS

Content management picked for the people editing it weekly, not for the developer configuring it once.

WordPressShopifyMagentoSanityStrapiCraft CMS

L06

DevOps & observability

Wired in from the first commit, so a bad hour is visible before the client notices.

GitHub ActionsCircleCIDockerTerraformSentryDatadog

The full eight-category stack lives on /services. If your engagement needs something not listed, mention it on the first call — these name what we work with most often, not the only things we’ll touch.

See the full stack

04 / 07

Three shapes. One team.

How engagements start.

Platform work reaches us in three states. The shape sets how the engagement is scoped — never who does the work, and never the standard it’s held to.

S01

Greenfield

Nothing exists yet.

Data model and architecture drawn before the first ticket
Scoped as a project, with a written SOW and milestone timeline
Decision records in your repo from the first commit

Best forA new platform at the core of an engagement you've just won.

S02

Rebuild or replatform

Something exists. It's in the way.

A written read on rebuild versus refactor before any proposal
Staged migration — the old system stays live until the new one earns traffic
Nothing switches off without a rollback path

Best forA legacy platform slowing the client's roadmap down.

S03

Extended team

The build is running. It needs hands.

Retained capacity in two-week sprints, named hours and outputs
Your repo, your tracker, your standards, your commit format
Senior review on every merge, including your team's

Best forAn in-house team that needs depth rather than headcount.

Scope is written down before anything gets built, and the ninety-day post-launch programme is costed into every build by default.

How pricing works

05 / 07

Questions worth answering up front

Common questions.

The engineers doing the build, in writing, as the decisions land. Every consequential choice becomes an architecture decision record in your repo — what we chose, what we rejected, why. You can overrule any of them. What you never get is a platform whose shape nobody can explain six months later.

You get an honest read before a proposal. Sometimes the answer is refactor and spend the budget elsewhere. Sometimes the old system genuinely can't carry what the client wants next. Either way it comes to you written down, with the reasoning, before anyone quotes a rebuild.

The repo with its history intact, tests on the critical paths, a README that boots the project on a clean machine, runbooks for anything that pages someone at night, and the decision records. Your agency owns all of it from the first commit — no escrow, no phased release.

Preview deploys on every change and a branch per outcome, in your repo and your tracker. Senior review before every merge. The lead from the first call stays on every check-in, so you aren't handed to a delivery manager once scoping ends.

Your client sees your brand on every staging URL, every commit format, every document. No Orizon name in the repo, on the invoice, or on the call. Mutual NDA and non-solicit by contract. If your client wants to meet the engineers, they meet your team.

You hear it the day we see it, not in a change order at the end. Anything outside the written SOW gets re-quoted on its own, so the original scope keeps its price. Silence about a slipping estimate is the failure mode this model is built against.

06 / 07

The partner that stays

Send us the platform brief.

The one that’s been on your desk because nobody can tell you what it costs to build properly. We’ll read it and tell you what we’d do with it — including the parts we’d talk you out of.

The brief, the deck, or the email thread. Whatever form it's in now is enough.
Whatever already exists. A repo, a staging URL, the old system's admin login, or nothing at all.
The date your client expects it live. If that date is the problem, say so — it changes what we'd recommend.

Partner with us 15 minutes. No pitch.

Mutual NDA, same dayWhite-label throughoutYou own it from commit one

After you hit send

What happens next.

01 · Within a day

A human reads it

You get a reply naming what we understood and what we'd need to know before saying anything useful. Not a calendar link.

02 · First call

Fifteen minutes, no pitch

With a co-founder and the engineer who'd lead it. Three questions, in order — the outcome, what's already running, what has to be true in twelve months.

03 · Written read

What we'd build, and what we wouldn't

The approach, the data model we'd draw, where the risk sits, and the parts of the brief we think are wrong. In writing, before any number.

04 · Then it's yours to decide

Scope on paper, then build

A written SOW with milestones, or the workshop as a standalone if you want the read without the build. Nothing gets built before it's on paper.

The partner that stays. We build what stays.

All nine capabilities

07 / 07