FAQ

With whatever you have. A paragraph, a problem you can't name yet, a competitor you don't want to resemble — all of it is enough to begin.

Send the brief and you get a reply within one working day: questions first, not a price list. Once the questions are answered we put the shape of the work, the schedule and the cost in writing, and nothing is signed before that.

Most projects start around $2–3k and go up from there. A short strategy sprint or a single page designed and built sits at the low end; a product with accounts, roles and real data behind it runs well past it. The price of your project is written down after the questions are answered, never before.

What moves the figure most: how many surfaces have to be designed, whether the interface is built as well as drawn, and how much of the system behind it is new.

An identity or a marketing site is usually measured in weeks. A product with accounts, roles, permissions and real data behind it is measured in months.

You get a schedule with the proposal, before any commitment, and it is broken into stages with something finished at the end of each one — so progress is visible rather than promised.

Yes. Development, product design, identity and strategy are separable, and plenty of projects use one or two of them.

We will tell you when splitting the work costs more than it saves. The usual case is a design handed to a team that cannot build it — that bill arrives later, but it always arrives.

The people who answer your brief. Our team is deliberately small, the same people carry a project from the first direction to the working release, and nothing is quietly handed to someone you never meet.

Yes — alongside in-house designers, with your developers, or inside a product that already exists and already has users.

We start by reading what is there. Work that ignores the decisions already made is the fastest way to a redesign nobody adopts.

You do. Everything we make for you — files, source, assets — is yours once the work is paid for, and we hand it over in a form your team can actually keep working in.

We ask for one thing in return: permission to show the work once it is public. If you would rather we didn't, that is fine and it changes nothing else.

A release is the point where the real use starts, so we stay reachable after it. Most projects carry on in smaller steps: what people actually do with the thing tends to argue with what everyone assumed.

If you would rather take it in-house from that point, we make sure the handover is complete rather than technically complete.

The most technically demanding products often sit inside private business processes and cannot be published as ordinary case studies. Those are described in the archive without the client's name or screens.

We sign NDAs, and we treat yours the way we treat the ones already signed — which is why those projects are described the way they are.