Websites & Apps

Websites, apps and the systems behind them.

Marketing sites, web apps, native iOS and Android apps, APIs (ways for one program to use another) and data pipelines. We build them fast to load, strict about security and easy for the next developer to read. Then we hand over the repository (the code and its full history, kept in one place).

See this page measured Talk to Daniel

Inputs: A problem, a brand and whatever already exists
Builds: Sites, web apps, native apps, APIs, pipelines
Measures: Speed budgets, security headers, tests that pin outputs
Hands over: The repository, the tests and the build guards

This page’s own structure, drawn at build from its HTML.

People read the top layer, crawlers follow the middle one and machines parse the bottom one.

14 headings · 53 links · 8 schema nodes

Build

What we ship

From the page to the pipeline.

Marketing sites

Static HTML that renders before any script runs, a strict content policy (a list of rules for what a page may load and run) and structured data (code that tells search engines what a page is about) on every page. This site is one.

Web apps

Customer portals, internal tools and dashboards. Quick to open, honest about loading, and clear about where every number came from.

Native apps

iOS and Android from one Expo and React Native codebase. Logic that matters is shared with the web version and pinned by tests, so the phone and the website can’t disagree.

Backends and APIs

Serverless and edge functions (small programs a host runs only when they’re called), scheduled jobs and the APIs your front ends call. Every function checks who’s asking before it spends anything.

Data pipelines

Daily jobs that fetch, check and store data. They record when each fact was true, and they fail loudly when a source changes shape.

Build

Live readout

This page, measured.

The readout below comes from your browser’s own performance APIs (the browser’s built-in tools for timing a page). We didn’t type any of the numbers. If your browser doesn’t report a metric, the field says so instead of guessing.

Page status and telemetry Build

html Build: 13.2 kB
css Build: 23.6 kB
js Build: 8.4 kB
3rd-party Build: 0
LCP: needs JS
CLS: needs JS
slowest input: needs JS
time to first byte: needs JS
transfer: needs JS
requests: needs JS
DOM elements: needs JS
cookies: needs JS
tier: needs JS

Shared logic

One engine, two platforms.

The investor app we built for ADJL Capital runs its underwriting engine on the phone. The engine files are the same ones the website runs, byte for byte, and tests hold both to the same answers.

one engine · two platforms Illustration

The website and the app run the same engine files.
Each module is copied byte for byte. None of them is ported.
Golden scenarios run against both copies, so any drift fails a test.
The phone needs no network to compute. Take it offline and it still recomputes.

How the app works

Build

Build guards

Checks your team inherits.

Every site we ship comes with checks that fail the build. Dead CSS, broken links, missing structured data, pages over budget and copy that claims what it can’t back up. Your team gets the checks along with the code.

npm run build Build

✓ check-css
✓ check-links
✓ check-claims
✓ check-contact
✓ check-motion
✓ check-markers
✓ check-usage
✓ check-voice
✓ check-seo
✓ check-provenance
✓ check-budget

Handover

What you get at the end.

Everything needed to run it without us.

The repository, with its history
Tests that pin the outputs that matter
The build guards, already wired in
Deployment config and security headers
A runbook (written steps for running the system and fixing it) for when something breaks
Design tokens (the named colors, sizes and fonts a design is built from), so the next page matches

Proof

Software that’s running now.

Each of these runs today.

Fair questions

Questions about software builds.

Which stack do you use?

Whatever fits the job. This site is Vite and plain TypeScript with no framework. The investor app is Expo and React Native. Backends run as serverless and edge functions. The scope explains each choice.

Can you work with our existing site?

Yes. Most of the time the cheapest fix lives inside what you already have. We work in your repository, to your conventions, and leave it easier to change than we found it.

Do you maintain what you build?

The handover is built so your own team can take it over. If you’d like us to stay on, that’s a separate written agreement with its own scope.

Start here

Tell us what’s slow, or what can’t be found.

One paragraph is plenty. Tell us what you want built, the step that costs the most, or the page that should rank and doesn’t. If you know why the obvious fix hasn’t worked, say that too.

Start a project

Email

daniel@adjlcapital.com

Email Daniel

Daniel reads and answers these himself, usually within a day or two. No sequence, no drip, and nothing sold to anyone.