FAQ
Questions,answered plainly.
Including the ones about money and about why our portfolio says “concept”. If yours is not here, ask it directly.
Working together
Projects where the outcome matters to the business — a product launch, a platform that operations depend on, a workflow that is costing real money. We are a good fit when there is a decision to make, not only a specification to implement.
With a conversation about the problem rather than the deliverable. From there we scope a piece of work with a defined outcome. If discovery is needed before anyone can scope honestly, we run that as its own short engagement.
Regularly. We can lead the work, sit inside an existing team, or take one workstream and hand it back documented. What we will not do is work in a way that leaves your team unable to maintain what we built.
That is a normal starting point and often the most valuable place to begin. Working out what should be built is part of the job, not a prerequisite for hiring us.
We work remotely with clients in multiple time zones. Written clarity and a predictable meeting rhythm matter more than a shared office.
Process and delivery
It depends entirely on scope, and we would rather scope it properly than quote a number here. What we can commit to is telling you the timeline before you commit to us, and telling you early if it changes.
We price per engagement based on scope, not by hourly rate cards. You get the number before work starts. If scope changes materially, we discuss it rather than absorbing it silently or invoicing a surprise.
Openly. Some change is discovery working correctly. We separate "we learned something" from "this is new scope" and make the trade-off visible so you can decide.
You do — the code, the designs and the assets, on completion. We do not hold products hostage in accounts you cannot access.
Either we stay on for maintenance and iteration, or we hand over with documentation your team can work from. Both are legitimate; neither should be a surprise at the end.
Capability
Yes. Strategy, design and engineering are the point of the studio — the handoffs between them are where most projects lose time and intent.
No. A significant part of the work is improving, extending or modernising software that already exists and cannot simply be switched off.
As an engineering capability with measurable cost and a measurable error rate. We look for tasks with volume, repetition and a checkable output, prototype narrowly, and evaluate before widening scope.
Predominantly JavaScript and TypeScript across the stack — Next.js and React on the front end, Node.js services and PostgreSQL behind them. We choose boring, well-supported technology unless there is a specific reason not to.
It is built in, not sold separately. We target WCAG 2.1 AA as a baseline on what we build, and can audit existing products against it.
About this site
Because that is what it is. The projects shown are internal design and engineering explorations, clearly marked as such. We would rather show honest work than invent client names, testimonials or results we cannot evidence.
We read every enquiry and reply personally. We have deliberately not published a response-time guarantee we have not committed to — you see a confirmation as soon as your enquiry is sent.
Still unsure
Ask us the awkward one.
Budget, timeline, whether we have done this exact thing before — we would rather answer it now than dance around it later.