P/01
The simplest thing that works, wins
A static HTML page that loads in under a second beats an elaborate framework that renders a spinner. Complexity is only ever justified by what it makes possible — never by what it signals.
About the studio
Small studio. Senior work.
Vangh Studio is deliberately small. You speak to the person who designs it, writes it, ships it and answers the phone when something needs changing. That's the whole proposition — and the reason the work tends to be direct.
01 — Background
The studio started with other people's spreadsheets.
Nearly every project here began the same way: a business doing something well, held back by admin. A garage tracking repairs on paper. A tyre fitter invisible on Google in his own town. A builder whose best proof of quality was trapped in a phone gallery. A competition series collecting five kinds of application in five different inboxes.
None of them wanted "digital transformation". They wanted a specific, annoying thing to stop being annoying. That turned out to be a much better brief than most, and it shaped how the studio works: find the expensive friction, build the smallest thing that removes it, then get out of the way.
Working across the UK, Romania and Spain — in English, Romanian and Spanish — has made one thing obvious. The technology is rarely the hard part. Fitting software to how a business genuinely operates, in its own language and its own vocabulary, is.
02 / Principles
Six positions,
held firmly.
P/02
You own everything
Code, repositories, domains, hosting accounts, database, analytics. Registered in your name where possible, transferred where not. A studio should be kept because it's useful, not because leaving is painful.
P/03
Say no to the wrong project
If an existing tool already solves your problem for £30 a month, you'll be told to buy it. Turning down work you don't need is the only sales technique worth relying on.
P/04
Probabilistic where it helps, predictable where it counts
AI handles judgement — reading, drafting, classifying. Deterministic code handles anything that has to be right every single time. Mixing those up is how impressive demos become expensive incidents.
P/05
Design is how it works
Typography, spacing, hierarchy and speed are not decoration applied at the end. They are the difference between a tool your team adopts and one they work around.
P/06
Plain English, always
Proposals, documentation and updates you can read without a glossary. If a technical decision can't be explained in two sentences, it probably hasn't been thought through properly.
03 / Capability
The toolkit, and
why it's chosen.
Tools are picked per project. This is what tends to get used, and roughly what for.
Interfaces
Next.js and React where an application needs state and accounts. Astro or hand-written HTML where a site needs to be fast and stay fast. Tailwind and shadcn/ui to keep interfaces consistent without a design system committee.
- Next.js
- React
- Astro
- TypeScript
- Tailwind
- shadcn/ui
- Preact
Data & back end
Postgres via Supabase for most systems, with row-level security so permissions are enforced by the database rather than trusted to the interface. Region chosen for the client's data, not for convenience.
- Supabase
- PostgreSQL
- Row-level security
- Node
- Python
- REST & webhooks
AI & automation
Claude for reasoning over documents and language, wrapped in deterministic tooling with validation and human approval where the stakes justify it. Model size matched to the job so running costs stay boring.
- Claude API
- Structured output
- Tool use
- Scheduled jobs
- Evaluations
Delivery
Version control from the first commit, preview deployments so you can see changes before they're live, and a production deploy that is a push rather than an event. Monitoring and analytics configured for consent, not just for data.
- Git
- Vercel
- Preview deploys
- GA4 + Consent Mode
- Schema.org
04 — Fit
A good fit, and a bad one.
Works well
- Owner-led businesses where the decision-maker is in the room
- Teams outgrowing spreadsheets, shared inboxes or paper
- Companies with one specific, expensive, repetitive process
- Founders needing a working prototype rather than a pitch deck
- Established firms whose website no longer reflects the business
Works badly
- Projects whose main requirement is "add AI to it somehow"
- Briefs where nobody can say what success would look like
- Work needing a team of ten and a twelve-month runway
- Anyone shopping purely on lowest hourly rate
- Rebuilds of things that already work perfectly well