Questions

Send us what you have — a rough idea, a Figma file, a half-built product, or a problem you cannot get past. We read it before we talk, then run a call to work out what you actually need built and whether we are the right studio for it.

If it fits, you get a written proposal: scope, sequence, price and dates. If it does not fit, we will say so and point you somewhere better.

Both, chosen to suit the risk. Fixed-price suits well-understood scope — a marketing site, a defined integration, a design system. You know the number up front and we absorb the estimate risk.

Time-and-materials suits products that will change as they meet users, which is most of them. You get a weekly cadence and can stop, pause or redirect at any week boundary.

What we avoid is fixed-price on vague scope. That arrangement only ends one of two ways: we pad the estimate, or we argue about change requests.

Yes — small enough that a first project is not a leap of faith, large enough that we can do something real. EDIT: state your minimum here (e.g. a two-week discovery, or a four-week build block).

Short paid discovery is usually the cheapest way for both sides to find out whether a longer engagement makes sense.

Often, yes. We start with a paid review of the codebase and infrastructure so both of us know what we are inheriting — what works, what is load-bearing, what is going to hurt.

You get that review as a written document with costs attached whether or not you continue with us. We would rather hand you an honest assessment than quietly inherit someone else's problems and bill you for the surprise.

No, but the first work will be shaping rather than building. We help decide what the product actually is, what the smallest version worth shipping looks like, and what question that version needs to answer.

Building the wrong thing well is the most expensive outcome available, so this stage is worth its cost.

It depends on scope, and any studio that quotes before understanding yours is guessing. What we can tell you is how the number is built: the size of the team, the number of weeks, and whether we are carrying estimate risk for you.

EDIT: add your rate card or typical project ranges here (e.g. what a landing site, an MVP and a full platform build usually land at). Without them this answer is honest but not useful.

You will always see a written estimate before work starts, and we flag it as soon as we think we are going to miss it — not at the end.

Fixed-price work is billed against milestones tied to something you can actually look at, not to internal phases. Time-and-materials is billed monthly in arrears against a log of what was done.

EDIT: state your deposit, invoice terms and accepted payment methods.

It will change — that is normal. On time-and-materials we simply reprioritise the next week. On fixed-price we price the change separately and you decide whether it is worth it before we build it.

Nothing gets quietly absorbed and nothing gets quietly billed. If a request moves the date or the number, you hear about it that week.

You do, in full, on final payment — source, design files, infrastructure definitions and accounts. We keep no hostage dependency on our own hosting, licences or accounts.

The only things we retain are generic, non-client-specific building blocks we bring to every project, licensed to you perpetually. EDIT: confirm this matches your contract before publishing.

Yes. Send yours over and we will sign it, or we can provide a standard mutual one.

By default we also will not show your project publicly without asking. If you would like it in our portfolio we will agree what can be shown first.

Less than you fear, more than zero. We need one person on your side who can make decisions without convening a committee, available for a weekly review and reachable during the week for questions.

Projects stall on unanswered decisions far more often than on engineering problems.

A shared channel for day-to-day questions, and a weekly review against a live URL. You look at the running software, not a status document.

We would rather show you something unfinished on week two than something polished and wrong on week eight.

Yes. Most communication is asynchronous by design, with a fixed weekly call at a time that works on both ends.

EDIT: state your working hours, base time zone and the overlap you can commit to.

The shape is more useful than a single number: discovery is measured in days, a first shippable release in weeks, an established product in an ongoing cadence.

EDIT: replace this with typical durations for the work you actually sell.

Where a date is genuinely fixed — a launch, an event, a funding round — say so at the start. We will hold the date and cut scope to meet it, which is the only reliable way to hit a deadline.

Mostly TypeScript across the stack: React and Next.js on the web, React Native for mobile, Node and Python on the server, PostgreSQL for data, Docker and AWS to run it.

We pick boring, well-supported tools on purpose. You should be able to hire someone to maintain this after we are gone, and that is much harder if we picked something fashionable.

Each service page lists the stack we reach for in that discipline.

Usually. Tell us what it is early — if it is something we cannot support well, we will say so rather than learn it on your budget.

We use AI tooling where it genuinely helps and review everything that ships. What you are buying is engineering judgement about what should exist, how it should be structured and how it fails — and that does not come out of a model.

We will not ship generated code we do not understand.

Yes, targeted at what actually costs you money when it breaks rather than at a coverage percentage. Critical user journeys get end-to-end tests that run on every change.

We would rather have a fast, trusted, smaller suite than a large one everybody has learned to ignore.

The running product, the repository with its history intact, infrastructure defined as code, environment and deployment documentation, and a walkthrough with whoever is taking it on.

The test we hold ourselves to: a competent engineer who has never met us should be able to clone the repo, run it locally and deploy it, using only what we left behind.

Yes — dependency and security updates, monitoring, and a defined route for when something breaks. See the maintenance service for what an ongoing arrangement covers.

EDIT: state your response times and support hours.

That is a normal end state, not a failure. You already own everything, and the handover documentation exists from day one rather than being written in a hurry at the end.

We will run a transition period with your new team at our normal rates. No exit fee, no hostage-taking.

If we built it wrong, we fix it at our cost. That is a defect, not a change request, and the distinction is not something we are precious about.

New requirements discovered after launch are a different thing, and we will be straight with you about which one we think it is.